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Para la mayoría, el término cracking! contiene matices relacionados con lo 
prohibido, lo desconocido y lo extraño. ¿Por qué? ¿En qué consiste realmente el cracking? 
¿Por qué resulta tan peligroso y qué defensas existen contra él? Entre otras cosas, este libro 
ayudará al lector a dar con la respuesta a estos interrogantes. La evolución del cracking ha 
ido siempre de la mano de la del anticracking. Estas dos técnicas no pueden sobrevivir la 
una sin la otra. No existiría protección de software sin al menos un conocimiento básico de 
las técnicas del cracking, y viceversa, no habría cracking sin un conocimiento mínimo 
sobre protección de software. 


Por tanto, este libro muestra a los desarrolladores cómo proteger su software frente 
al cracking, así como las técnicas empleadas por los crackers?. Sólo de esta manera 


' Nota del traductor: dada la ambivalencia con la que se aplica el término “cracking” a lo 
largo del libro (tanto para indicar una actividad relacionada con la protección del software como otra, 
ilegal, destinada a violar el código de un producto), la numerosa cantidad de técnicas que abarca (el 
autor lo considera una ciencia) y, sobre todo, la falta de equivalente satisfactorio en castellano que 
refleje esta complejidad semántica, se ha optado por dejarlo como un extranjerismo en el texto del 
libro, al igual que “anticracking?. 


2 Nota del traductor: si bien a priori el lector puede tender a pensar que la mayoría de los 
“crackers” son, sencillamente, infractores, el propio uso que hace el autor del término “cracker” (y 
que algo más adelante en este mismo prólogo aclara) le despoja de todo matiz moral. No existe voz 
equivalente en castellano ni siquiera aproximada. 
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conocerá el programador el tipo de amenazas que se ciernen sobre sus aplicaciones y a 
probarlas antes por sí mismo. Se aplica así el viejo principio del arte de la guerra: conoce a 
tu enemigo. 


Este libro no sólo muestra los conceptos básicos, sino que también recoge algunas 
técnicas avanzadas de cracking y anticracking, además de una gran cantidad de 
información: desde la simple descripción de algoritmos de protección hasta el proceso de 
creación de un codificador PE propio, Si bien los profesionales del campo lo encuentren 
valioso, el libro no está dirigido a ellos en absoluto. Se ha escrito principalmente para 
principiantes, quienes deben de poseer los fundamentos mínimos de los lenguajes de 
programación. 


A lo largo del libro se presenta una gran cantidad de código escrito en ensamblador, 
Que no asuste a nadie, Todo el mundo sabe que el ensamblador no es precisamente el 
mejor lenguaje de programación para principiantes. Por esa razón, todos los fragmentos del 
código están comentados”; así, cada operación resultará obvia incluso para quienes no 
sepan ensamblador en absoluto. Indirectamente el lector también obtendrá con este libro 
cierto conocimiento de ensamblador. Con ánimo de facilitar su lectura, se incluye un 
capítulo de referencia con la descripción de las instrucciones básicas de este lenguaje. No 
obstante, considérese que el ensamblador constituye un lenguaje de programación muy útil 
y muy eficaz que, aunque no sea un requisito para entender el texto, sí debería 
considerarse seriamente aprenderlo. 


En todo caso, ¿por qué se emplea ensamblador? La respuesta es bien sencilla: los 
lenguajes de programación de alto nivel resultan poco ágiles y sus posibilidades, muy 
escasas a la hora de programar las protecciones de software. Razón por la que el autor ha 
decidido emplear código ensamblador con lenguajes de programación de alto nivel. Con 
ello se facilita su uso en lenguajes populares como C++ o Delphi además de poder portar 
el código (en este caso se ha empleado el compilador Microsoft Visual C++ 6.0). De esta 
manera, los desarrolladores podrán cortar y pegar fácilmente el código fuente necesario 
para incluirlo en sus proyectos. 


Tras un largo período de dedicación a este campo, se puede afirmar que no existe 
una protección invencible. Ahora bien, sí es posible crear una protección de software 
resistente a la mayoría de las técnicas de ataque cuya anulación además acarree una gran 
cantidad de tiempo. Precisamente es su duración el factor crucial que hace satisfactoria una 
protección. Una protección satisfactoria puede definirse como la que resiste la mayor 
cantidad de tiempo. Por otra parte, siempre existirán infractores a quienes no les importe 
pasarse horas, días o incluso semanas intentando anular una protección. En la mayoría de 


Y Nota del traductor: y traducidos. También se han traducido los mensajes y literales de los 
programas siempre que con ello no quedara alterada la lógica del código. 
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las ocasiones, no se trata de una cuestión económica o de índole similar sino su deseo de 
vencer, de ser el mejor. Representa su entretenimiento, su afición. Por otro lado, hay 
empresas de software para quienes el tiempo significa dinero. Cuanto más tiempo lleve 
anular una protección, más ingresos obtendrá la empresa por ventas. Mucha gente, en vez 
de quedarse esperando a una versión pirata o a un crack válido, seguramente comprarán el 
programa original, lo que redundará en beneficio de las empresas, ¡siempre y cuando el 
programa ilegal no esté disponible antes que el original! El período inmediatamente 
posterior a su comercialización se revela casi siempre crucial. Resulta sumamente 
comprometido el que una versión pirata de un programa que ha suscitado gran 
expectación, se encuentre en Internet horas después de que se ponga a la venta. 


Antes de adentrarse en profundidad en el mundo del cracking conviene realizar 
algunas puntualizaciones sobre la organización de este libro. Puesto que no existen límites 
definidos entre las distintas técnicas del cracking y la mayoría de ellas se complementan 
entre sí, muchos de los capítulos de este libro podrían reorganizarse de otra manera. Se ha 
ordenado según la frecuencia en el uso de la información que contienen y no según ningún 
otro criterio, 


¿En qué consiste el cracking? 


DEFINICIÓN DE CRACKING 


El cracking se puede describir como el grupo de técnicas empleadas para codificar, 
analizar y estudiar los principios de un programa sin disponer de su código fuente. Con un 
caso práctico quedará mucho más clara esta breve definición. Cuando un desarrollador 
crea un programa, comienza escribiendo el código fuente en el lenguaje de programación 
que haya elegido para acabar compilándolo (en un programa ejecutable). Llegado este 
punto, nadie podría editar el programa sin disponer del código fuente y realizar una nueva 
compilación. Esto es falso, y en ello es precisamente en lo que se basa el cracking. 


La técnica de ingeniería inversa constituye la piedra angular del cracking, se basa en 
la descompilación, o compilación inversa, de un programa a un lenguaje de programación, 
generalmente, el más básico, esto es, ensamblador. Existen descompiladores capaces 
también de descompilar un programa a un lenguaje de programación de alto nivel. No 
obstante, no se han recogido en este libro por resultar problemáticos, y faltos de la 
fiabilidad y de la exactitud requeridas en la práctica. 


Aunque parezca que el objetivo principal del cracking consista en alterar el software 
con ciertas modificaciones de su funcionalidad original (normalmente cambios relativos a 
la seguridad o a las propiedades de la protección), excede la sencilla actividad de editar el 
código del programa. Puede llegar a anularse una buena parte de los sistemas de protección 
sin practicar ninguna modificación al programa: hallando la contraseña, el número de 
registro, etc., e incluso simplemente estudiando el código de programa. 
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Lo que importa verdaderamente a un cracker es un buen conocimiento de 
ensamblador. Exagerando y forzando un poco esta afirmación, podría decirse que todo 
programador en ensamblador representa un cracker en potencia, y viceversa. Lo que queda 
demostrado por la mala interpretación y error que cometen muchas personas siempre 
dispuestas a denunciar como criminal a cualquier cracker (puede que la causa resida en 
cierto número de películas estadounidenses o en el desconocimiento de que el cracking 
también consiste en una técnica de optimización de la programación; son sólo sus aspectos 
negativos los que se aplican con fines ilegales). El afirmar que todos los crackers son 
criminales equivale a afirmar que todos los físicos nucleares que sepan cómo crear una 
bomba atómica son genocidas. La realidad se muestra en conjunto bien distinta. Al igual 
que hay personas buenas y malas, hay crackers buenos y malos. Mientras que el primero se 
esfuerza en aprender tanto como pueda, en obtener la mayor experiencia posible, en 
compartirla, en ayudar a los ingenieros de desarrollo de software indicando dónde residen 
los puntos débiles de las protecciones y en procurar proteger el software contra el cracking, 
el último hace exactamente lo contrario: vulnera el software y lo hace circular ilegalmente. 


HERRAMIENTAS DE CRACKING ELEMENTALES 


Como ya ha quedado dicho, el procedimiento básico consiste en la descompilación 
de un programa en un lenguaje de programación, a ensamblador en la mayoría de las 
ocasiones. El cracker podrá estudiar el programa de forma pasiva, desensamblarlo con un 
desensamblador (descompilador que efectúa una compilación inversa en ensamblador) 
para obtener su código ensamblador estático, o bien aplicar un programa de depuración, un 
depurador, para depurar el programa. Al constituir uno de los pasos claves el uso frecuente 
de algún depurador para realizar el análisis del programa, resulta pertinente intentar evitar 
su utilización (o al menos, obstaculizarla en gran medida). Razón que conduce a los 
infractores a aplicar distintos métodos y programas que enmascaren su depurador. El 
programa más conocido empleado para detectar un depurador y "dejar las cosas en su 
sitio" se denomina Frogslce. 


Si se efectuaran alteraciones al código del programa, éstas deberán guardarse en 
algún lado. Con este propósito existen varios editores hexadecimales; alternativamente, se 
puede modificar el código del programa directamente en memoria mediante un cargador. 


También figuran los volcadores, programas diseñados para guardar en disco el 
contenido de la memoria. Muy útiles para almacenar datos importantes descodificados por 
el programa automáticamente. ProcDump representa un buen ejemplo: es un volcador y 
descodificador que también incluye otras muchas funciones. 


No se preocupe el lector que no conozca las herramientas y técnicas mencionadas. 
Se irá familiarizando con ellas progresivamente conforme vaya examinando los ejemplos 
ofrecidos a lo largo de este libro. 
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¿MERECE LA PENA PROTEGER EL SOFTWARE O 
RESULTA INEVITABLE EL CRACKING? 


Toda protección está destinada a ser anulada tarde o temprano; ahora bien, no debe 
ponerse en duda la protección del software, puede apreciarse cómo se extiende por todo el 
mundo la apatía que encierra esta duda. Los problemas puestos de manifiesto por la 
piratería de software son de índole muy compleja y exigen soluciones multidisciplinares. 
La cuestión no radica en cómo impedir la piratería, sino en cuánto se puede aprender 
acerca del comportamiento de los cracks y en cómo proteger el software durante la mayor 
cantidad de tiempo posible difundiendo los secretos de los métodos de cracking. Pueden 
localizarse cientos de libros sobre “hacking” destinados a divulgar los trucos habituales 
para penetrar en las redes de ordenadores, con el mismo propósito se ha escrito este libro, 
pero en este caso orientado al software. 


CONTENIDOS DEL CD ADJUNTO 


El CD adjunto no sólo contiene el código fuente de los ejemplos de este libro, 
sino algo parecido a lo que podría ser el paquete completo de cracking y anticracking 
(dentro del conjunto de los programas gratuitos y de código compartido —en inglés, 
“shareware” —, naturalmente). Se han reunido las últimas versiones de casi todos los 
compresores y codificadores PE más conocidos, sus correspondientes descompresores 
y descodificadores, ProcDump incluido, unos cuantos volcadores, generadores de 
parches y cargadores, editores PE y rastreadores, y calculadoras de ubicaciones, 
desensambladores, depuradores, FrogsIce y muchos otros programas y herramientas — 
en pocas palabras, la mayoría del software mencionado en este libro y todo lo 
necesario para empezar a proteger software-—. Algunos programas no pudieron 
incluirse en el CD por rehusar sus autores a dar su consentimiento. Con objeto de 
compensar esta ausencia, en el capítulo 10 se ofrecerá una lista con las direcciones en 
Internet donde descargarse el software. 


CAPÍTULO 1 


MÉTODOS DE PROTECCIÓN Y SUS 
PUNTOS DÉBILES 


<< ———_—_—_—_ 


En este capítulo se van a describir algunos de los métodos de protección de software 
más extendidos, señalando sus vulnerabilidades teniendo en cuenta que resulta 
prácticamente imposible crear una protección de software invencible. 


Existen varios métodos fiables de proteger el software sin necesidad de conocer 
contraseñas, el código fuente, el fichero de registro, o cualquier otro requisito que exija el 
programa. 


CIFRADO 


Este método de protección consiste en emplear datos cifrados para descifrarse 
posteriormente tecleando un número de registro (contraseña, etc.) sobre el que no se 
realiza ninguna comprobación, tampoco se realiza sobre la clave de descifrado 
(característica muy importante) —los datos quedan así descifrados—, si se produjera 
algún error, la clave generada sería errónea. 


El único modo de sortear este tipo de protección se reduciría a intentar un 
ataque masivo, lo que, suponiendo que se haya aplicado un buen algoritmo de cifrado, 
constituye una tarea casi insuperable. Si el programa emplea un algoritmo tipo RSA y 
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un código de 2048 bits, quedará protegido con seguridad incluso frente a entidades 
gubernamentales si bien se ha mejorado mucho el proceso de resolución del problema 
que supone la factorización (o se halle una solución alternativa). 


Desgraciadamente, esta técnica encierra su propia debilidad. Resulta válida sólo 
hasta que el cracker consiga la clave. Tan pronto la obtenga de un conocido que se haya 
registrado o la encuentre en Internet, nada evitará que pueda guardar los datos de forma no 
cifrada. 


PROGRAMAS INCOMPLETOS 


Otra forma de evitar violar un programa consiste en retirar aquella parte del 
código que pudiera ser atacado. Resulta bien simple. Al crear un versión para 
demostración o de código compartido (de funcionalidad limitada) de un programa, 
resulta preferible empaquetar estas versiones distinguiéndolas de la versión integra del 
programa (y no al revés, donde la versión de demostración se convierte en la definitiva 
tras introducir el número de serie...). De este modo, se puede suprimir aquella parte del 
código de la que se pueda prescindir. 


Cualquier programa en demostración o de código compartido (“shareware”) en 
el que se evite la presencia material del código constituye un programa incompleto. No 
hay forma de modificar algo que no existe en el programa. El cracker tendría que 
programar el código él mismo. 

El usuario registrado normalmente recibe la versión íntegra del programa. Lo 
que, no obstante, exige un mecanismo de copia sofisticado para evitar que la versión 


completa del programa se difunda ilegalmente. Numerosos programadores han perdido 
dinero por esta razón. 


CLASIFICACIÓN BÁSICA DE LOS TIPOS DE 
PROTECCIÓN DISPONIBLES 


e Duración limitada 

e Número limitado de ejecuciones 

e Otras restricciones numéricas 

+ Número de registro o contraseña-número de serie 


e Fichero clave 


CORA-MA 
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Las técnicas de protección tienden a utilizarse de forma conjunta: por ejemplo, se 
pueden encontrar versiones limitadas por tiempo de un programa que se desbloquea al 


Programas limitados 

Clave hardware (“dongle”) 

Comprobación de la presencia del CD 
Protección contra la copia del CD 

Protección comercial 

Compresores y codificadores para formato PE 


Programas en Visual Basic 


introducir el número de serie correcto o un fichero temporal, etc. 


Para ilustrar lo peligroso que resulta superar las protecciones, mostraremos las 
vulnerabilidades de algunos de los métodos de protección de software anteriormente 


mencionados. Ello le podría convencer de la necesidad de empezar a proteger su software, 


Duración limitada 


Los creadores de software que aplican métodos de protección basados en la 
duración limitada pretenden asegurarse de que su software no va a volver a funcionar 
pasado el período de prueba o que sus opciones van a quedar restringidas de una u otra 


manera. 


Figura 1-1. Cuadro de diálogo introductorio de la versión de prueba del programa 


CloneDVD2 
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Cualquier programa que utilice este método de protección normalmente guardará la 
fecha en el momento de su instalación (los algoritmos avanzados lo guardan en varios 
sitios) —por ejemplo, en registros, ficheros, etc.— y así poder comparar dicho valor con la 
fecha actual en cada ejecución (varias veces, si fuera posible). Su inconveniente radica en 
que la fecha actual del sistema depende enteramente del usuario; estos algoritmos se 
pueden sortear cambiando simplemente la fecha del sistema a otra anterior, 


Los últimos mecanismos de protección se basan en métodos mucho más 
sofisticados para calcular la fecha actual —esto es, a partir de ficheros del sistema—. Su 
estructura, sin embargo, apenas se ha visto modificada, ni tampoco el procedimiento 
necesario para su supresión. Puede parecer absurdo que hasta las últimas protecciones 
comerciales utilicen una estructura similar de protección por duración limitada que sus 
predecesores —aun cuando se complemente con otro tipo de protección—. La estructura 
de la mayoría de protecciones de este tipo sigue el modelo siguiente. 


mov eax, [ebp+123456h] // obtención de la fecha actual 
// y almacenándola en el 
// registro EAX 


cmp eax, 1Eh // comparándola con la fecha/hora 
//límite, etc. (almacenada en EBX) 
jl contiue // si la fecha actual es menor que 


// el valor límite, el programa 
// puede continuar 


Al cambiar en este caso concreto la última instrucción a una bifurcación 
incondicional (IMP), el proceso siempre saltará a la etiqueta “continue” 
independientemente del resultado de la instrucción CMP anterior, así la protección quedará 
deshabilitada. No resulta necesario enfatizar que sin otro tipo de protección dicho 
algoritmo no serviría de nada. 


CG RA-MA CAPÍTULO 1: MÉTODOS DE PROTECCIÓN Y SUS PUNTOS DÉBILES _ 5 


CENT 


as er 


Yoaa eran peros 
Pee ula yaa copy PE Era now. 


FociHeks cosa Y 


Figura 1-2. Agotada la versión con duración limitada de PE-Explorer 


La mayoría de los algoritmos difieren únicamente en la manera de cerciorarse de la 
fecha actual. A continuación se enumera en una lista las funciones API más utilizadas 
para este propósito: 


GetLocalTime 
La función GetLocal Time devuelve la fecha y hora locales. 


VOID GetLocalTime ( 
LPSYSTEMTIME lpSystemTime // hora del sistema 
); 


Valores obtenidos 
Esta función no devuelve ningún valor. 


GetSystemTime 
La función GetSystemTime almacena la fecha y hora del sistema actuales. La hora del 
sistema se expresa en UTC (“Universal Time, Coordinated”). 
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VOID GetSystemTime ( 
LPSYSTEMTIME lpSystemTime // hora del sistema 


); 


Valores obtenidos 
Esta función no devuelve ningún valor. 


GetFileTime 


La función GetFileTime devuelve la fecha y hora en la que se creó un fichero, la 
última vez que se accedió y la última vez que se modificó. 


BOOL GetFileTime ( 


HANDLE hFile, // manejador de fichero 
LPFILETIME lpCreationTime, // hora de creación 
LPFILETIME lpLastAccessTime, // hora del último acceso 
LPFILETIME lpLastWriteTime // hora de la última 


// escritura 
; 


Valores obtenidos 

Si la función devuelve algún valor, no será nulo. 

Si la función no devuelve nada, su valor será cero. Para obtener más información sobre 
el error, invóquese GetLastError. 


CompareFile Time 
La función CompareFileTime compara dos horas de un fichero. 


LONG ComparerFileTime ( 
CONST FILETIME *1pFileTimel, // primera hora del 
// fichero 
CONST FILETIME *1pFileTime2 // segunda hora del 
// fichero 


); 


Valores obtenidos 
El valor devuelto ha de ser uno de los siguientes: 


Valor Significado 


ll Primera hora del fichero menor que la 
| segunda. 


0 Primera hora del fichero igual que la 
segunda. 


1 Primera hora del fichero mayor que la 
segunda. 
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GetTickCount 

La función GetTickCount devuelve el número de milisegundos que han transcurrido 
desde que se arrancó el sistema. Depende de la precisión del reloj del sistema. Para 
obtener la precisión del reloj del sistema utilícese la función 
GetSystemTimeAdjustment. 


DWORD GetTickCount (VOID) ; 


Valores obtenidos 
El valor devuelto será el número de milisegundos transcurridos desde que el sistema se 
arrancó. 


GetTimeZoneInformation 

La función GetTimeZonelnformation obtiene los parámetros de la franja horaria 
actual. Estos parámetros controlan la traducción entre el UTC (“Universal Time, 
Coordinated”) y la hora local. 


DWORD GetTimeZoneInformation ( 
LPTIME_ZONE_INFORMATION lpTimeZoneInformation // franja 
// horaria 


); 


Valores obtenidos 
Si se devuelve algún valor, será uno de los siguientes: 


Valor Significado 


TIME_ZONE_ID_UNKNOWN El sistema no puede determinar la franja horaria actual. 
También se obtiene este error al invocar la función 
SetTimeZonelnformation con valores de desplazamiento 
pero sin fechas con que realizar la traducción. 

Windows NT/2000/XP: se obtiene este valor cuando no 
se emplea el cambio horario al llegar el verano en la franja 
horaria actual, ya que no hay fechas de traducción. 


TIME_ZONE_ID_ STANDARD El sistema opera en el intervalo indicado por el miembro 
StandardDate de la estructura 
TIME_ZONE_INFORMATION. 

Windows 95/98/Me: se devuelve este valor cuando no se 
emplea el cambio horario al llegar el verano en la franja 
horaria actual, ya que no hay fechas de traducción. 


TIME_ZONE_ID_DAYLIGHT El sistema opera en el intervalo indicado por el miembro 
DaylightDate de la estructura 
TIME_ZONE_INFORMATION. 
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Si la función falla, el valor devuelto es TIME_ZONE_ID_INVALID,. Si se deseara 
mayor información sobre el error, invóquese GetLastError, 


El cracker alcanzará su objetivo si consiguiera encontrar la función utilizada 
(normalmente una API) por la protección para cerciorarse de la fecha actual. 


Otras restricciones numéricas 


La situación con este tipo de protección se asemeja mucho a las basadas en límite 
temporal. En este caso, el propio programa o algunas de sus características tienen un 
número de usos limitado (ejecuciones) y no una fecha límite en la que se detenga su 
funcionamiento. Un programa con este modelo de protección almacena el número de veces 
que se ha empleado una función relacionada con las restricciones temporales (de nuevo, en 
varios sitios si fuera posible) y comprueba si todavía se puede utilizar. 


Aunque pueda resultar algo más difícil identificar los algoritmos profesionales 
frente a los programas que utilizan un límite temporal, esta protección será inviable si no se 
combina con otros mecanismos complementarios. Dado que la mayoría de los 
programadores no resultan muy inventivos y reinciden en guardar en los mismos sitios el 
número de veces que se puede utilizar el programa, no resulta nada difícil detectar la 
protección. Bien es cierto que tampoco son muchos los lugares donde guardar la 
información: o en el registro de Windows o en ficheros (fácilmente rastreables). 


> 


Emelcome to Easy GIF Animator 


Thanks for taking time to evaluate Easy GIF Animator! 


You can use this program For 30 times without any charge. To continue using 
the program after your trial has expired, please purchase the software. 


Great Reasons to Get Easy GIF Animator Now. 
Complete set of features 
Create GIF animations quickly and easily 
Best price in category 


Unconditional 30 day money-back guarantee 


Your questions are welcome at our Customer Support Center 
You have 23 trials left 


(_ Purchase —) [ Evaluste —] 


Figura 1-3. Una versión no registrada de Easy GIF Animator permite al usuario 
ejecutarlo 30 veces únicamente 
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Número de registro 


La protección por número de registro y sus equivalentes (campo de comprobación, 
combinación secreta de claves, etc.) constituye indudablemente una de las más empleadas 
en el software actual (empleada principalmente en los programas de código compartido). 
Con frecuencia esta protección se combina con restricciones de otro tipo que quedan 
anuladas al introducir el número de registro. 


DK | 
Ordering Info | 
License 


THE ARCHIVE UTILITY WINDOWS 


WINzÍ?.. 


If you paid the WinZip registration fee: 


If you paid the WinZip registration fee and received a registration number hom WinZip 
Computing or an authorized reseller, please enter your name and registration number here 
EXACTLY as lhey appear in the instructioris, or click "Help" for additional information, 


1f you have not yet paid the WinZip registration fee: 


If you downloaded an evaluation version of WinZip, oril you received this version o WinZip 

on a disk or CD, with a book, or with other hardware or software, and you have not paid the 

WinZip registration fee, you are: licensed to use WinZip for evaluation purposes only. Click 
"Continue Unregistered”, or click "Help" for additional information. 


357 Name: | 
Registration $: 


Cancel Continue Unregistered | Help | 


Figura 1-4. El antiguo y buen WinZip con su ventana de registro 


Hay muchas formas de llevar a la práctica una protección basada en números de 
registro. El número se puede almacenar directamente en el código del programa para 
compararlo con el que se introduzca (éste constituiría el peor de los casos) o bien generarlo 
dinámicamente, o partir de los datos introducidos o a partir de parámetros concretos del 
ordenador (configuración de hardware, etc.). Son muchas las alternativas. 


El cracker, al intentar suprimir este tipo de protección, intentará obtener el número 
exigido por el programa depurando el código (véase el capítulo 2), o bien modificará el 
programa para que parezca que se comporta como si hubiera introducido el número 
correcto sin hacerlo realmente. En este caso, el cracker generalmente tendrá que modificar 
el programa en varios lugares dado que la comprobación del número introducido 
(normalmente guardado en el registro de Windows) con el número real se realiza varias 
veces —cuando el programa se arranca, cuando se invoca cierta función y, de forma más 
sofisticada, al azar—. 
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Normalmente son los principiantes los que adoptan esta estrategia de ataque 
contra este tipo de protección ya que resulta mucho más simple que intentar entender 
las rutinas, con frecuencia muy complicadas, utilizadas para la generación de números 
de registro. Si bien este último caso puede suponer mayor esfuerzo al tener que 
localizar otros algoritmos de comprobación, el programador podría haber ahorrado 
trabajo al cracker si hubiera utilizado una sola función para todas las comprobaciones. 
Éste es uno de los errores que con más frecuencia se cometen. Resulta crítico la 
manera en la que se haya codificado el programa. 


Sin duda alguna, la mejor manera de proteger no sólo un programa sino otros 
recursos mediante un número de registro, pasa por cumplir con los consejos dados al 
principio de este capítulo. El número de registro debería emplearse para cifrar aquellas 
partes del programa que queden accesibles únicamente después de registrarse. Aunque 
el cracker suprimiera otros mecanismos de protección, no podrían recuperarse las 
funciones cifradas del programa. Únicamente mediante la introducción de los datos de 
registro correctos, el programa quedará descifrado y listo para su uso. La seguridad de 
este tipo de protección resulta directamente proporcional a la seguridad del algoritmo 
de cifrado. 


When: you bo GetRight you are amáled a registration code to enter to tell GetRight that you 
have paid. 


If your registration code looks like 123456-12345-12345-12345-12345, just enter it below! 


If your registration code looks like numbers 123456789012, you have an 
older code. For version 5.0, the codes have been changed. You will 
need to get the free update to pour code. 


Figura 1-5. Cuadro de diálogo de registro de GetRight 


Veamos ahora un sencillo ejemplo de lo que no debería de ser un mecanismo de 
protección: 
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CorrectNumber = 
CreateNumber (Keyed_inName,Keyed_inCompany) ; 
if (CorrectNumber == Keyed inNumber) 


( 


MessageBox (“Registro correcto",NULL,MB_OK); 


pa 


else 


( 


MessageBox (“Registro incorrecto “NULL, MB_O0K); 


El algoritmo muestra alguno de los errores más comunes cometidos por los 
autores que aplican este tipo de protección. El primero y más serio, consiste en que el 
número de registro se devuelva directamente mediante una función (cuyos parámetros 
están contenidos en la información tecleada por el usuario —su nombre y el de su 
empresa—). El leerlo tras invocar la instrucción CALL desde un programa de 
depuración no puede resultar más fácil. El algoritmo de protección nunca debe 
diseñarse de manera que invoque a una función que a su vez devuelva el número, 
contraseña, etc., correctos. ¿Por qué no intentar dividir el número real entre los datos 
de un campo y cifrarlo todo para mayor seguridad? Cuanto más complicado sea el 
método empleado, más difícil resultará la identificación del número de registro. Otro 
error consiste en comprobar el número tecleado utilizando bucles con la función 5É. 
No debe de olvidarse lo sencillo que resulta encontrar una instrucción CMP. pertinente 
para visualizar el número de registro o invertir la lógica del algoritmo entero. 


Constituye otro error serio, el uso de la evidente función API MessageBoxA y, 
de hecho, la utilización de una API como tal. El establecer el punto de corte (el 
mandato dado al programa de depuración para suspender la ejecución del programa y 
proceder a la depuración —para mayor información véase el final de este capítulo y la 
sección sobre puntos de corte del capítulo 2—) en esta función APL, conducirá 
directamente al corazón del algoritmo de comprobación. Considérese por otra parte la 
posibilidad de que el usuario obtenga información a partir de los datos introducidos. 
¿Se puede realmente aceptar que nadie conozca las funciones API GetWindowTextA o 


GetDlgltemTextA? 
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Registration Key: 
í 
To obtain a valid registration Key, you must order this software. Pricing is 
115$:20 for tegistered 1.» users, US$ 40 for the standard version (without 
ASIO, Akai CD and VST instrument support) and US$ 75 for the full 


featured professional versión. Reler to. www vitualsampler. de 
for details. 


Preset MIDI options Preset Operations Splt optiorrs 


vera ENE (O 
Kbd Mode: (3 Import Preset 


Figura 1-6. Y los números ganadores son ... 
Estas son las robustas características con que los programadores dotan a sus 
programas para “protegerlos” mediante estos métodos. Al emplear algoritmos similares 
a éste, las únicas personas contra las que se protege al software son los usuarios 


legales. Hasta un principiante puede suprimir este tipo de protección. A continuación 
se enumera una lista de las funciones API más utilizadas con este propósito: 


GetDlgltemText / GetDlgltemTextA / GetDlgltemTextW 


La funciónGetDlgltemText obtiene el título o texto asociado a un 
control de un cuadro de diálogo, 


UINT GetDlgltemText( 
| HWND hDlg,  //manejador del cuadro de diálogo 
int nIDDlgltem, // indentificador de control 


LPTSTR IpString, // puntero al buffer de texto 
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intnMaxCount // tamaño máximo de la cadena 


): 


Valores obtenidos 


De ejecutarse con éxito, el valor devuelto por la función indica el 
número de TCHARs copiados al buffer sin incluir el carácter nulo de 
finalización. 


De ejecutarse sin éxito, el valor devuelto será cero. Si se deseara 
información más detallada del error, invóquese GetLastError. 


GetWindowLong / GetWindowLongA / GetWindowLongW 


La función GetWindowLong obtiene información sobre la ventana 
señalada. También devuelve el valor de 32 bit (largo) en el 
desplazamiento para la memoria extra de la ventana. 


Si se está obteniendo un puntero o un manejador, esta función será 
sustituida por GetWindowLongPtr. (Punteros y manejadores son de 32 
bits en los sistemas Windows de 32 bits y de 64 en los sistemas 
Windows de 64 bits.) Si se descara escribir código compatible tanto 


con las versiones Windows de 32 bits como de 64 bits, utilícese 
GetWindowLongPtr. 


LONG GetWindowLong( 
HWND hWnd, // manejador de ventana 
intnIndex // desplazamiento del valor que se desea obtener 


) 


14 CRACKING SIN SECRETOS 


CGRA-MA 


CO RA-MA CAPÍTULO 1: MÉTODOS DE PROTECCIÓN Y SUS PUNTOS DÉBILES 15 


16 


CRACKING SIN SECRETOS 


CRA-MA 


De no ejecutarse con éxito, la variable indicada por IpTranslated 
contiene el valor FALSE, y el valor obtenido, cero. Obsérvese que al 
ser cero un valor traducido posible, no indica por sí sólo error alguno. 


Si IpTranslated fuera NULL, la función no indicará información 
alguna sobre éxito o fracaso. 


Si el parámetro bSigned fuera TRUE, indicando que el valor obtenido 
es un valor entero señalado, asígnese al valor obtenido un tipo entero. 
Si se deseara información más detallada del error, invóquese 
GetLastError, 


SendDlgltemMessage / SendDlgltemMessageA / 
SendDlgltemMessage W 


La función SendDIgltemMessage envía un mensaje al control indicado 
en un cuadro de diálogo. 


LRESULT SendDlgltemMessage( 
HWND hDlg, — // manejador del cuadro de diálogo 
int nIDDlgltem, // identificador de control 
UINT Msg, // mensaje 
WPARAM wParam, // primer parámetro del mensaje 
LPARAM IParam  // segundo parámetro del mensaje 
); 
Valores obtenidos 


El valor obtenido contiene el resultado tras procesar el mensaje según 
el mensaje enviado. 
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REGISTRO INTERACTIVO 


Durante los últimos años se viene apreciando una tendencia a realizar de forma 
interactiva los registros de todo tipo. Esta técnica es aplicable de muchas maneras. Desde 
el modo más simple de todos, donde el servidor (el de la empresa que realiza los registros) 
comprueba que la información de registro resulta correcta, al más sofisticado, donde el 
código del programa nuevo se envía directamente al usuario vía Internet. 


Estos métodos representan un notable paso hacia delante en la lucha contra la 
piratería en el software. La parte más vulnerable de la protección, la comparación 
efectuada entre la información introducida y la de referencia, se lleva a cabo en el servidor 
y no en el ordenador del cliente. A pesar de todo, el programa todavía resulta susceptible a 
muchas formas de ataque. Aunque dependa de los datos que se le envíen, el cracker puede 
sortear algunas restricciones (esto es, funciones no cifradas). También sigue siendo muy 
difícil de resolver el problema de las copias de versiones del programa. Una vez que el 
programa guarda la información sobre su registro ya efectuado, le hace vulnerable. 


La mejor forma de protección interactiva consiste en habilitar este tipo de función 
directamente en Internet en vez de en el código del programa. Los grandes juegos en red o 
con servidores constituyen un buen ejemplo. Se exige el código de registro (además de las 
copias legales) para acceder al servidor y jugar al juego interactivamente. Si el código 
introducido ya lo ha utilizado otro usuario o resulta incorrecto, es evidente que algún 
usuario no autorizado está intentando acceder al sistema. 


Las protecciones interactivas también sirven para que las empresas controlen los 
registros realizados y vayan creando una base de datos sobre sus usuarios. No obstante, 
todo ello puede parecer injusto para quienes no tengan acceso a Internet. Si bien estos 
usuarios pueden tener la voluntad de registrarse, se les fuerza a utilizar versiones piratas 
para evitar los problemas que conlleva el registro interactivo. 


Fichero clave 


Debido a que su ejecución resulta mucho más difícil, la protección mediante 
ficheros clave tiende a evitarse y olvidarse. Sin embargo, el invertir varias horas diseñando 
un buen algoritmo de protección basado en este método compensará el esfuerzo realizado. 


Este método alternativo se asemeja en varias maneras a la protección mediante 
números de registro. Al igual que en este caso, no se trata de comprobar si es o no correcto 
el fichero clave, sino de utilizar la información contenida en él —ya sea para descifrar 
códigos posteriores del programa o incluso para crearlo—. La única gran ventaja del 
fichero clave consiste en que puede albergar una relativa gran cantidad de datos —desde 
información de registro hasta el propio código que ha de completar el programa original 
(como funciones de las que carecía la versión no registrada) —. 
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Al violar este tipo de protección, el cracker intentará principalmente reconstruir 
el fichero clave utilizando el código de programa, que a menudo resulta más revelador 
de su contenido y estructura de lo que sería deseable. Si se asume una buena 
programación que añada código nuevo al programa basado en esta técnica, volverá 
imposible la tarea de reconstrucción. O, con mayor exactitud, será posible siempre que 
el cracker reconstruya el código de programa él mismo. Por tanto, en este caso el 
cracker habrá de optar por suprimir las restricciones del programa sin el fichero clave. 
Podrá suprimir otras protecciones (por ejemplo, un límite temporal), pero no será 
capaz de recuperar las funciones ausentes del programa. 


Los desarrolladores normalmente desconocen las posibilidades que brinda este 
tipo de protección, y así emplean el fichero clave para guardar información sobre el 
usuario —su nombre, el nombre de su empresa, etc.—. Sin embargo, ésta no resulta 
una solución nada segura, con esta sencilla estructura, el fichero clave se podrá 
reconstruir sin grandes problemas. Recuérdese: cuanto más complicada la estructura, 
mejor. 


La protección mediante ficheros clave combinados con el uso de otras técnicas 
constituye, a mi parecer, uno de los métodos de protección más potentes para proteger 
el software eficazmente. Al igual que sucede con la protección mediante números de 
serie, debiera controlarse la difusión de la información sobre registros ya efectuados. 
Y de nuevo, una alternativa para alcanzar tal finalidad radica en vincular el registro 
con un ordenador específico (según su hardware, etc.), que para llevarla a cabo, no 
debe olvidarse que, como sucede con otras protecciones contra el copiado, la 
necesidad de volver a registrarse al efectuar cambios en el hardware puede desanimar a 
los posibles usuarios a que compren el software. 


Añado a continuación un ejemplo con los errores más frecuentes cometidos al 
programar una protección basada en ficheros clave. Resultaba obvio que los 
programadores no son conscientes de las posibilidades que les brinda este tipo de 
protección. 


DWORD NOBR; 
BYTE Key[9] = (1,2,3,4,5,6,7,8,9); // campo con los 
// valores correctos del fichero clave 
HANDLE File = CreaterFile(“key file.key”, 
GENERIC_READ, FILE SHARE _READ,NULL, 
OPEN_EXISTING, FILE _ATTRIBUTE_NORMAL,NULL) ; 
// obtención del manejador de fichero 
if (File == INVALID_HANDLE VALUE) 


( 


MessageBox ("Error en el registro”, NULL,MB_OK); 


return; 


) 
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BYTE *pMem = new BYTE [GetFileSize (File, NULL) ]; 
// asignación de memoria 
ReadFile (File, pMem, 
GetFileSize(File,NULL),SNOBR, NULL) ; 
// carga del fichero en memoria 


for (DWORD i = 0; i < GetFileSize(File,NULL); i++) 


if (pMem[i] != Key[il) // ¿contenido del fichero 
// correcto? 

( 
MessageBox (“Registration 
failed” ,NULL,MB_OK); 
CloseHandle (File); 
return; 

) 


) 


MessageBox (“Registro realizado”, NULL, MB_0K); 


CloseHandle (File); 
delete[] pMem; 


El mayor error relacionado con este tipo de protección consiste en la 
comprobación periódica del contenido del fichero comparándolo con el campo que 
contiene los valores correspondientes del fichero clave, lo que permitiría reconstruir el 
fichero clave en cuestión de segundos. Como ya se indicó con anterioridad, dichos 
valores han de utilizarse, y no reducirse simplemente a su comprobación. 


A continuación se enumera en una lista las funciones API más utilizadas para 
este propósito: 


CreateFileA / CreateFileW 


La función CreateFile crea o abre los objetos siguientes y obtiene un 
manejador para poder acceder al objeto: — 


- Consolas 


- Recursos de comunicaciones 
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- Directorios (apertura solo) 
- Dispositivos de disco 

- Ficheros 

- Mailslots 


- Pipes 


HANDLE CreateFile( 


LPCTSTR IpFileName, // nombre de fichero 
DWORD dwDesiredAccess, //modo de acceso 
DWORD dwShareMode, // modo compartido 


LPSECURITY_ATTRIBUTES IpSecurityAttributes, // SD 


DWORD dwCreationDisposition, // cómo crear 
DWORD dwFlagsAndAttributes, // atributos del fichero 
HANDLE hTemplateFile // manejador de la plantilla 


// del fichero 


Valores obtenidos 


De ejecutarse con éxito, el valor obtenido será un manejador abierto 
contra el fichero indicado. Si existiera antes de la invocación a la 
función y dwCreationDisposition fuera CREATE_ALWAYS o 
OPEN_ALWAYS, la invocación a GetLastError será 
ERROR_ALREADY_EXISTS (aun cuando la función termine bien). 
Si el fichero no existiera antes de la invocación, GetLastError 
obtendrá el valor cero. 
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Si la función no se ejecuta con éxito, el valor obtenido será 
INVALID  HANDLE_VALUE. Si se deseara mayor información 
sobre el error, invóquese GetLastError. 


ReadFile 


La función ReadFile lee datos de un fichero, comenzando en la 
posición indicada por el puntero. Tras una operación de lectura, el 
puntero se ajusta según el número de bytes realmente leídos a no ser 
que el manejador de fichero se haya creado con el atributo de 
solapamiento. Si el manejador de fichero se ha creado para input y 
output (1/0) coincidentes (solapamiento), la aplicación deberá ajustar 
la posición del puntero del fichero tras la operación de lectura. 


Esta función se ha diseñado tanto para operaciones síncronas como 
asíncronas. La función ReadFileEx se ha diseñado sólo para 
operaciones asíncronas. Permite a una aplicación realizar otros 
procesos durante la operación de lectura de un fichero. 


BOOL ReadFile( 
HANDLE hFile, // manejador de fichero 
LPVOID IpBuffer, // buffer de datos 


DWORD nNumberOfBytesToRead, // número de bytes en lectura 
LPDWORD IpNumberOfBytesRead, // número de bytes leídos 


LPOVERLAPPED IpOverlapped — // buffer para solapamiento 


) 
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Valores obtenidos 


La función ReadFile obtiene un valor cuando alguna de las 
condiciones siguientes resulta verdadera: finaliza una operación de 
escritura al final del pipe de escritura, se han leído el número de bytes 
solicitados, o se ha producido un error. 


De terminar con éxito, el valor obtenido por la función será distinto de 
Cero. 


Si el valor obtenido es distinto de cero y el número de bytes leídos es 
cero, entonces el puntero del fichero señalará más allá del final del 
fichero actual en el momento de la operación de lectura. Por el 
contrario, si el fichero se abrió con FILE_FLAG_OVERLAPPED y 
IpOverlapped no es NULL, y el valor obtenido es FALSE, 
GetLastError obtendrá ERROR_HANDLE_EOF cuando el puntero 
del fichero señale más allá del final del fichero actual. 


De no acabar con éxito, el valor obtenido será cero. Si se deseara 
mayor información sobre el error, invóquese GetLastError. 


WriteFile 


La función WriteFile escribe datos a un fichero; está diseñada tanto 
para operaciones síncronas como asíncronas. La función comienza 
escribiendo datos al fichero en la posición indicada por el puntero del 
fichero. Tras finalizar la operación de escritura, el puntero se ajusta 
según el número de bytes realmente escritos a no ser que el manejador 
de fichero se haya creado con FILE_FLAG_OVERLAPPED, Si el 
manejador de fichero se ha creado para input y output (1/0) 
coincidentes (solapamiento), la aplicación deberá ajustar la posición 
del puntero del fichero tras la operación de escritura. 
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Esta función se ha diseñado tanto para operaciones síncronas como 
asíncronas. La función WriteFileEx se ha diseñado sólo para 
operaciones asíncronas. Permite a una aplicación realizar otros 
procesos durante la operación de escritura de un fichero. 


BOOL WriteFile( 
HANDLE hFile, // manejador de fichero 
LPCVOID IpBuffer, // buffer de datos 


DWORD nNumberOfBytesToWrite, — // número de bytes en 
escritura 


LPDWORD IpNumberOfBytes Written, // número de bytes escritos 


LPOVERLAPPED IpOverlapped // buffer para solapamiento 


) 


Valores obtenidos 


De acabar con éxito, el valor obtenido por la función será distinto de 
cero. 


De no terminar con éxito, el valor obtenido será cero. Si se deseara 
mayor información sobre el error, invóquese GetLastError. 


SetFilePointer 


La función SetFilePointer desplaza el puntero de fichero a un fichero 
abierto. 


Esta función almacena el puntero de fichero en dos valores tipo 
DWORD. Si se deseara trabajar con mayor comodidad con punteros 
de fichero mayores a un único valor DWORD, utilícese la función 
SetFilePointerEx. 
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DWORD SetFilePointer( 
HANDLE hFile, // manejador de fichero 
LONG IDistanceToMove, // bytes para desplazar puntero 
PLONG IpDistanceToMoveHigh, // bytes para desplazar puntero 


DWORD dwMoveMethod // punto de comienzo 


); 


Valores obtenidos 


De acabar con éxito la función SetFilePointer y 
IpDistanceToMoveHigh resulta NULL, el valor obtenido será el 
DWORD de menor orden del nuevo puntero de fichero. Si 
IpDistanceToMoveHigh no resulta NULL, la función obtendrá el 
DWORD de menor orden del nuevo puntero de fichero, y guardará en 
el DWORD de mayor orden el nuevo puntero de fichero en el LONG 
señalado por dicho parámetro. 


De no acabar con éxito la función y IpDistanceToMoveHigh resulta 
NULL, el valor obtenido será INVALID_SET_FILE_POINTER. Si se 
deseara mayor información sobre el error, invóquese GetLastError. 


De no terminar con éxito la función y IpDistanceToMoveHigh no es 
NULL, el valor obtenido será INVALID_SET_FILE_POINTER. Sin 
embargo, como INVALID_SET_FILE_POINTER es un valor válido 
para el DWORD de menor orden del nuevo puntero de fichero, deberá 
invocarse GetLastError para determinar la causa del error. Si se 
hubiese producido un error, GetLastError obtendrá un valor distinto a 
NO_ERROR. Consulte al final de este capítulo la sección 
Observaciones si se desea un ejemplo de este caso. 


Si el nuevo puntero de fichero hubiese obtenido un valor negativo, la 
función fallará, el puntero de fichero no se moverá y el código 
obtenido por GetLastError será ERROR_NEGATIVE_SEEK. 
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GetPrivateProfilelnt / GetPrivateProfileIntA / GetPrivateProfilelntW 


La función GetPrivateProfileInt obtendrá un valor entero asociado a 
una clave en la sección indicada de un fichero de inicialización. 


Esta función se incluye sólo por compatibilidad con las aplicaciones 


Windows de 16 bits. Las aplicaciones deberían guardar su 
información sobre inicialización en el registro del sistema. 


UINT GetPrivateProfilelnt( 
LPCTSTR IpAppName, // nombre de la sección 
LPCTSTR IpKeyName, // nombre clave 


INT nDefault, // valor obtenido si no se encuentra el nombre 
/Iclave 


LPCTSTR IpFileName // nombre del fichero de inicialización 


) 


Valores obtenidos 


El valor obtenido será el equivalente entero de la cadena que sigue al 
nombre clave indicado en el fichero de inicialización indicado. Si no 
se encuentra la clave, el valor obtenido será el valor definido por 
omisión. Si el valor de la clave es menor a cero, el valor obtenido será 
cero. 


GetPrivateProfileString / GetPrivateProfileStringA / 
GetPrivateProfileStringW 
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La función GetPrivateProfileString obtiene una cadena a partir de una 


sección dada en un fichero de inicialización. 


Esta función se incluye sólo por compatibilidad con las aplicaciones 
Windows de 16 bits. Las aplicaciones deberían guardar su 
información sobre inicialización en el registro del sistema. 


DWORD GetPrivateProfileString( 
LPCTSTR IpAppName, // nombre de la sección 
LPCTSTR IpKeyName, // mombre clave 
LPCTSTR IpDefault, // cadena por omisión 
LPTSTR IpReturnedString, // buffer de destino 
DWORD nSize, // tamaño del buffer de destino 
LPCTSTR IpFileName //mombre del fichero de inicialización 


) 


Valores obtenidos 


El valor obtenido será el número de caracteres copiados al buffer, 
excluyendo el carácter nulo de terminación. 


Si ni IpAppName ni IpKeyName son NULL y el buffer de destino 
resulta demasiado pequeño para albergar la cadena solicitada, ésta 
quedará truncada y seguida por un carácter nulo, el valor obtenido 
será igual a nSize menos uno. 
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Si IpAppName o IpKeyName son NULL y el buffer de destino resulta 
demasiado pequeño para albergar todas las cadenas, la última cadena 
quedará truncada y seguida por dos caracteres nulos. En este caso, el 
valor obtenido será igual a nSize menos dos. 


WritePrivateProfileString / WritePrivateProfileStringA / 
WritePrivateProfileStringW 


La función WritePrivateProfileString copia una cadena en una sección 
específica de un fichero de inicialización. 


Esta función se incluye sólo por compatibilidad con las aplicaciones 
Windows de 16 bits. Las aplicaciones deberían guardar su 
información sobre inicialización en el registro del sistema. 


BOOL WritePrivateProfileString( 
LPCTSTR IpAppName, // nombre de sección 
LPCTSTR IpKeyName, // nombre clave 
LPCTSTR IpString, // cadena por añadir 
LPCTSTR IpFileName // fichero de inicialización 


): 


Valores obtenidos 


Si la función consigue copiar la cadena al fichero de inicialización, el 
valor obtenido será distinto a cero. 


De no terminar con éxito la función, o limpia la versión guardada con 
el fichero de inicialización accedido por última vez, el valor obtenido 
será cero. Si se deseara mayor información sobre el error, invóquese 
GetLastError. 
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Programas limitados 


Existen muchas maneras de reducir la funcionalidad de los programas. De 
hecho, ciertas formas de protección pueden considerarse también programas limitados. 
Sin embargo, aquí me refiero más concretamente a aquellos programas que tienen 
distintos botones inhabilitados y opciones inaccesibles desde los menús. 


JESRURITOS rruityCoops 3 Cel) 
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notallowedín den 


Figura 1-7, Resulta prácticamente imposible guardar nada con esta versión, en 
demo de Fruity Loops 


El problema principal de este tipo de protecciones no radica en la característica 
de control en sí, sino en el hecho de que dicho mecanismo olvida proteger el propio 
código del programa. Resulta obvio que de vez en cuando habrá que añadir al 
programa una o dos de las características deshabilitadas (por ejemplo, para demostrar 
que la versión en demo no puede realizar lo mismo que la versión completa), de 
manera que el código del programa controlado por el mecanismo de protección nunca 
debe permanecer en el programa. 


Si la funcionalidad queda habilitada transcurridos unos segundos (lo que indica 
que el código está presente), resulta recomendable volver a comprobar que se cumple 
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la condición para su activación o bien aplicar la estrategia recomendada en los tipos de 
protección anteriormente comentados —cifrar y posteriormente descifrar el código 
cumplidas las condiciones que permitan su uso, o procesarlos de alguna otra manera, si 
se dan dichas condiciones—. 


El lector podrá comprobar por sí mismo cuán fácil resulta activar un botón o una 
opción de menú deshabilitados. 


This demo version does not allow you to save your work, 
You must obtain the registered version Lo save | 


Figura 1-8. Inhabilitar la grabación parece ser la manera más frecuente de limitar 
un programa 


Como en otras veces, se enumera en una lista las funciones API más utilizadas 
para este propósito: 


InsertMenultem / InsertMenultemA / InsertMenultemW 


La función InsertMenultem inserta una opción de menú nueva en una 
posición dada. 


BOOL InsertMenultem( 
HMENU hMenu, // manejador de menú 
UINT ultem, // identificador o posición 


BOOL fByPosition, — // significado de ultem 


LPCMENUITEMINEO Ipmii // información de la opción de menú 


» 
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Valores obtenidos 


De terminar con éxito la función, el valor obtenido será distinto de 
cero, 


De no terminar con éxito la función, el valor obtenido será cero. Si se 


deseara mayor información sobre el error, invóquese GetLastError. 


SetMenulteminfo / SetMenultemInfoA / SetMenulteminfoW 


La función SetMenultemInfo modifica la información sobre una 
opción de menú. 


BOOL SetMenultemInfo( 
HMENU hMenu, // manejador de menú 
UINT ultem, // identificador o posición 
BOOL fByPosition,  // significado de ultem 
LPMENUITEMINEO Ipmii // información de la opción de menú 


E 


Valores obtenidos 


De terminar con éxito la función, el valor obtenido será distinto de 
Cero. 


De no terminar con éxito la función, el valor obtenido será cero. Si se 


deseara mayor información sobre el error, invóquese GetLastError. 
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EnableMenultem 


La función EnableMenultem habilita, deshabilita o vuelve gris una 
opción de menú indicada, 


BOOL EnableMenultem( 
HMENU hMenu, // manejador de menú 
UINT ulDEnableltem, // opción de menú por actualizar 


UINT uEnable // opciones 


) 


Valores obtenidos 


El valor obtenido indica el estado anterior de la opción de menú 
(MF_DISABLED, MF_ENABLED, o MF_GRAYED). Si la opción 
de menú no existiera, el valor obtenido sería —1. 


EnableWindow 


La función EnableWindow habilita o deshabilita la entrada de datos 
desde el ratón o teclado en la ventana o control indicados. Cuando 
queda desabilitada, la ventana no recibirá pulsaciones ni del ratón ni 
del teclado. Cuando se habilite, la ventana sí recibirá dicha 
información. 
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BOOL Enable Window( 
HWND hWnd, — // manejador de ventana 


BOOL bEnable // habilitar o deshabilitar input 


) 


Valores obtenidos 


Si la ventana fue deshabilitada anteriormente, el valor obtenido será 
distinto de cero. 


Si la ventana no fue deshabilitada anteriormente, el valor obtenido 
será cero. Si se deseara mayor información sobre el error, invóquese 
GetLastError. 


Protección Hardware 


La protección por hardware (“dongle”, en inglés) consiste en una pequeña unidad 
auxiliar conectada al ordenador, normalmente al puerto paralelo o a algún otro (USB, 
serie). Esta unidad de hardware resulta muy difícil de duplicar, en ello se basa este tipo de 
protección. Contiene cierto tipo de memoria con datos y código de programa, lo que le 
permite comunicarse con el software protegido y auxiliarle en la realización de ciertas 
tareas: desde comprobar su presencia hasta codificar o descodificar secuencias de 
caracteres. 


Desgraciadamente, a la mayoría de los programadores no se les puede molestar para 
que estudien la documentación de las funciones ofrecidas por esta unidad de hardware (a 
diferencia de los crackers, ya que la documentación resulta accesible públicamente) y se 
ciñen a comprobar si está o no presente. Resulta innecesario señalar que empleando un 
mensaje de error y una función API del tipo MessageBox, por ejemplo, la protección 
quedará anulada inmediatamente, 
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Figura 1-9. Ejemplo de protección por hardware 


No obstante, existen otras formas más sofisticadas de protección aplicando las 
estrategias ya recomendadas al describir los anteriores tipos de protección. La unidad de 
hardware puede vincularse directamente al programa (el código del programa puede residir 
en la propia unidad, los valores obtenidos por la unidad se emplearán para descifrar el 
código pendiente del programa, etc.), lo que significa que la protección no podrá anularse 
sin la unidad de hardware. Éste parece el mejor modo de proteger el software mediante una 
unidad de hardware. 


Otros tipos de protección más cara demuestran una norma: cuanto más trabaje con 
acierto el equipo de software en el programa, menos tendrán que preocuparse de proteger 
su producto ni comprar otro sistema de protección complementario, cuyo manejo 
desconocen, creyendo que cuanto más caro resulte el precio mejor la protección. Con todo, 
las empresas gastan una fabulosa cantidad de dinero en sistemas de protección que no son 
capaces de explotar completamente. 


El popular programa 3D Studio Max representa un ejemplo típico. A pesar de su 
eran popularidad y su alta demanda de copias ilegales (no todo el mundo puede 
permitirse comprar un programa cuyo precio asciende a varias docenas de euros), los 
programadores aún no han sido capaces de conseguir una protección eficaz. 
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'or you are using the virong lock, 


vr the lock dovice drivers ere not running. 


log 30 Stud 
Figura 1-10. 3D Studio MAX indica la ausencia de la unidad de hardware 


Un ejemplo real de estos programas recibía varios valores desde la unidad de 
hardware sólo para realizar increíbles operaciones matemáticas, que este autor 
renunció a comprender por la preocupación que produjo en su salud mental. ¡Los 
varios centenares de líneas de código tan sólo se remitían a obtener dos valores: 0 si la 
unidad de hardware no estaba conectada o 1 si sí lo estaba! Este ejemplo ilustra lo 
pueriles que pueden llegar a ser algunos desarrolladores de software. 


Comprobación de la presencia del CD 


Comprobar la presencia del CD en la unidad de CD-ROM se ha convertido en un 
estándar y en el método más empleado, no sólo para proteger software, sino también para 
comprobar de manera simple si el programa va a ejecutarse con un CD falso en la unidad 
de disco, lo que podría hacer peligrar su correcto rendimiento. 


Data File Error 


Starcraft is unable to read a required file. Your Starcraft CD may not be in 
the COROM drive. Please ensure that the Starcraft disc ís in the CDROM 
drive and press OK. To leave the program, press Exit, 


sm | 


Figura 1-11. Resulta dificil ejecutar StarCraft sin la presencia de su CD 


Este tipo de protección se diseñó en el pasado, cuando un grabador de CD era un 
objeto muy valioso, los CDs no eran tan baratos ni accesibles y no todo el mundo disponía 
de un CD-ROM. Por lo tanto, el tamaño del programa se reducía eliminando secuencias de 
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video, música, documentación o código DirectX y se ejecutaba directamente desde el disco 
duro. 


Actualmente existen varias formas de verificar la presencia de un CD concreto en la 
unidad de CD-ROM: comprobando la etiqueta del CD, comprobando el espacio libre, 
comprobando los ficheros que se eliminan con frecuencia, etc. 


AR WARS 


ohantino 


Please insert the CD nto your CD-ROM player and try again. 
Regist 


Uninsti 


Figura 1-12, Aquí también resulta indispensable el CD 


La mayoría de estos algoritmos desgraciadamente se basan en la invocación a una 
función APT bien conocida: GetDriveTypeA, empleada para detectar la unidad CD-ROM 
en el sistema, lo que facilita su localización y supresión. Además, dichas técnicas resultan 
absolutamente superfluas cuando prácticamente todo el mundo puede grabar sus CDs. Hoy 
en día cualquiera puede grabar en CD lo que necesite, este tipo de protección se centra más 
bien en dificultar la difusión de software ilegal en Internet. El tamaño de una versión 
integra de un juego “limpiado” de esta manera puede quedar reducida a una décima parte 
de su tamaño original, y transferido cómodamente a través de Internet incluso para 
aquellos que dispongan de una conexión lenta. 


A continuación se enumera en una lista las funciones API más utilizadas para este 
propósito: 
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CreateFileA / CreateFileW 


- viz, Key-file 


GetDiskFreeSpace / GetDiskFreeSpaceA / GetDiskFreeSpaceW 


La función GetDiskFreeSpace obtiene información sobre el disco 
indicado, incluyendo su cantidad de espacio libre. 


La función GetDiskFreeSpace no puede abarcar tamaños superiores a 
2 GB. Si se desea que la aplicación trabaje con discos de gran 
capacidad, utilícese la función GetDiskFreeSpaceEx. 


BOOL GetDiskFreeSpace( 
LPCTSTR IpRootPathName, // directorio raíz 
LPDWORD IpSectorsPerCluster, — // sectores por cluster 
LPDWORD IpBytesPerSector, //'bytes por sector 
LPDWORD IpNumberOfFreeClusters, // clusters libres 


LPDWORD IpTotalNumberOfClusters // clusters en total 


JE 
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Valores obtenidos 


De terminar correctamente, la función obtiene un valor distinto de 
cero. 


De no terminar correctamente, la función obtiene un valor distinto de 
cero. Si se deseara mayor información sobre el error, invóquese 
GetLastError. 


GetDriveType / GetDriveTypeA / GetDriveTypeW 


La función GetDriveType indica si una unidad de disco se puede 
retirar, es un disco fijo, un CD-ROM, un disco RAM, o un disco de 
red. 


UINT GetDriveType( 


LPCTSTR IpRootPathName // directorio raíz 


Ja 


Valores obtenidos 


El valor obtenido indica el tipo de disco. Puede ser uno de los valores 
siguientes: 
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Valor Significado 

DRIVE_UNKNOWN No se puede determinar el tipo de 
unidad. 

DRIVE_NO_ROOT_DIR El directorio raíz es incorrecto, por 


ejemplo cuando no se ha montado 
ningún volumen en el directorio. 


DRIVE_REMOVABLE El disco se puede retirar de la unidad. 

DRIVE_FIXED El disco no se puede retirar de la 
unidad. 

DRIVE_REMOTE Disco remoto (red). 

DRIVE_CDROM CD-ROM. 

DRIVE_RAMDISK Disco RAM (memoria). 


GetFullPathNameA / GetFullPathNameW 


La función GetFullPathName obtiene todo el directorio (“path”) y el 
nombre de un fichero indicado. 


DWORD GetFullPathName( 
LPCTSTR IpFileName, // nombre de fichero 
DWORD nBufferLength, // tamaño del buffer de directorio 
LPTSTR IpBuffer, — // buffer de directorio 


LPTSTR *IpFilePart // dirección del nombre del fichero en el 
/directorio 


); 


Valores obtenidos 


De terminar la función correctamente, el valor obtenido será la 
longitud en TCHARs, de la cadena copiada a IpBuffer, sin incluir el 
carácter nulo de terminación. 
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Si el buffer IpBuffer resulta demasiado pequeño para contener el 
directorio completo (“path”), el valor obtenido será el tamaño del 
buffer, en TCHARSs, necesario para guardar el directorio completo 
(“path”). Por tanto, si el valor resultante fuera mayor que 
nBufferLength, invóquese la función de nuevo con un buffer 
suficientemente grande como para albergar el directorio completo 
(“path”). 


Si la función no terminase bien por cualquier otra razón, el valor 
resultante será cero. Si se deseara mayor información sobre el error, 
invóquese GetLastError. 


GetLogicalDrives 


La función GetLogicalDrives obtiene una máscara de bits 
representando las unidades de disco disponibles. 


DWORD GetLogicalDrives(VOID); 


Valores obtenidos 


Cuando la función termina con éxito, el valor obtenido es una máscara 
de bits con la representación de los discos actualmente disponibles en 
el sistema. El bit en posición 0 (el menos significativo) indica la 
unidad A, el de la posición 1, la unidad B, el de la posición 2, la 
unidad C, y así sucesivamente. 


Si la función no terminase bien por cualquier otra razón, el valor 
resultante será cero. Si se deseara mayor información sobre el error, 
invóquese GetLastError. 


GetLogicalDriveStrinesA / GetLogicalDriveStringsW 
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La función GetLogicalDriveStrings guarda en un buffer una cadena 
con la que se indica los discos válidos del sistema. 


DWORD GetLogicalDriveStrings( 
DWORD nBufferLength, // tamaño de buffer 
LPTSTR IpBuffer  // buffer de la cadena de discos 


) 


Valores obtenidos 


De terminar con éxito, el valor obtenido será la longitud, en 
caracteres, de las cadenas copiadas al buffer, sin incluir el carácter 
nulo de finalización. Obsérvese que un carácter nulo ANSI-ASCU 
emplea un byte, pero el carácter nulo Unicode emplea dos. 


Si el buffer no es lo suficientemente grande, el valor obtenido será 
mayor que nBufferLength. Es el tamaño del buffer necesario para 
albergar la cadena de las unidades de disco. 


Si la función no terminase bien por cualquier otra razón, el valor 
resultante será cero. Si se deseara mayor información sobre el error, 
invóquese GetLastError. 


GetVolumelnformationA / GetVolumelInformationW 


La función GetVolumelInformation obtiene información sobre un 
fichero y volumen del sistema de un directorio raíz indicado. 
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BOOL GetVolumelnformation( 


LPCTSTR IpRootPathName, // directorio raíz 

LPTSTR IpVolumeNameBuffer, // buffer del nombre del 
/Ivolumen 

DWORD nVolumeNameSize, // longitud del buffer de 
//nombre 


LPDWORD IpVolumeSerialNumber, //n* de serie del 
//volumen 


LPDWORD IpMaximumComponentLength, // longitud máxima 
// del nombre del fichero 


LPDWORD IpFileSystemFlags, // opciones del fichero del 
//sistema 


LPTSTR IpFileSystemNameBuffer, — // buffer del nombre del 
//fichero del sistema 


DWORD nFileSystemNameSize // 1ongitud del buffer 
//para el nombre del fichero del sistema 


Valores obtenidos 


Si se obtuviera toda la información, el valor resultante será distinto de 
cero. 


Si no se obtuviera toda la información, el valor resultante será cero. Si 
se deseara mayor información sobre el error, invóquese GetLastError. 


Compresores y codificadores PE 


A pesar de que se dedique en este libro un capítulo íntegro al formato de fichero PE, 
hay dos términos que conviene aclarar con antelación: codificador PE y compresor PE. La 
razón es bien simple: puesto que estas dos herramientas representan los métodos de 
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protección frente al cracking más utilizados y se utilizarán a lo largo de todo el libro, 
resulta pertinente describirlos con brevedad. 


¿Qué es un codificador/compresor PE? Una herramienta que permite codificar (y en 
el caso de los compresores, comprimir) el código ejecutable del programa. La 
descodificación se realiza transparentemente en el momento de la ejecución y con ello se 
evita instalar otro programa. Con este método se dificulta enormemente la edición directa 
del código y otras técnicas de cracking. 


Si se desea más información, acúdase al capítulo 7. 


Protección contra la copia del CD 


Debido al creciente número de copias de CDs no originales, la mayoría de las 
empresas especializadas en protección de software se centran en las técnicas anticopia, 
cuyo fin consiste en prevenir la realización de una copia precisa de un CD. Con 
posterioridad se tratarán las protecciones comerciales, ahora, los principios básicos de la 
protección contra las copias de CD. 


DETERIORO FÍSICO DEL CD 


Los CDs protegidos de este modo deterioran fisicamente el CD —por ejemplo, 
con incisiones, partes ilegibles de la superficie, etc.— con lo que resulta sumamente difícil 
realizar operaciones de copia con exactitud. Incluso las mejores unidades de CD-ROM no 
son capaces de crear una copia perfecta de CDs así protegidos, o bien su producción 
acarrearía docenas de horas con pobres resultados. 


A causa del coste que conlleva estas modificaciones especiales y la fabricación de 
los CDs, este modo de protección apenas se ha empleado en unos pocos casos. 


FICHEROS DE TAMAÑO FALSO 


Esta técnica bastante extendida consiste en incluir ficheros con un tamaño falso 
en el CD. Un fichero de este tipo puede alcanzar 1 GB e incluir varios de ellos en un 
solo CD, 


Por esta razón, el tamaño total del CD puede superar aparentemente varios 
GBs. Lo que impide copiar el CD a un disco y volverlo a grabar en otro CD. La mejor 
forma de solucionar este problema consiste en duplicar el CD tal cual, ficheros 
incluidos. La mayoría de estas protecciones o comprueban la presencia de dichos 
ficheros en el CD, o bien este fichero contiene datos fundamentales para el programa 
(por ejemplo, el propio programa de instalación). Ésta es la causa de que resulte 
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esencial copiar los mencionados ficheros. No obstante, existen protecciones oscuras 
que ni comprueban la presencia de estos ficheros en el CD ni los necesitan para la 
ejecución del programa. Como ejemplo de este monumental defecto, puede citarse la 
enciclopedia checa Diderot. Resulta difícil creer que el programa pueda ejecutarse sin 
problemas tras copiar todo excepto los ficheros de tamaño falso (por no mencionar el 
hecho de que la protección no realiza ninguna comprobación con el CD). 


CDs SOBREDIMENSIONADOS 


Este tipo de protección, empleada en el pasado, consistía en producir una densidad 
de datos superior en el CD original, con lo que se veía aumentada su capacidad. Los CDs 
así protegidos podrían alcanzar una capacidad ligeramente superior a los 74 minutos, como 
en esa época aún eran difíciles de conseguir CDs de 80 minutos, de manera que para 
copiar el CD era preciso omitir algo de información. 


En cuanto surgieron los discos de 90 minutos, este método de protección se volvió 
absolutamente inútil. Incluso desde que existe el modo de escritura “raw”, la mayor parte 
de las grabadoras de CDs actuales son capaces de sobredimensionar los discos (y escribir 
por encima del límite recomendado) y apurar aún más su capacidad. 


TOC (“TABLE OF CONTENTS” EN INGLÉS) ILEGAL 


El formato definido por ISO permite únicamente un solo bloque de datos por CD. 
Cuando un disco se protege de esta manera, contiene varios bloques de datos, lo que 
lógicamente provoca un error al intentar grabarlo. Existen, no obstante, unos cuantos 
programas de grabación de CDs que ignoran esta anomalía y funcionan sin inconveniente 
alguno. Por lo que este método de protección apenas sí supone obstáculo para copiar un 
CD. 


FICHEROS AGRUPADOS 


El agrupar los ficheros no impide la copia del CD, pero sí evita suprimir parte de su 
contenido (vídeo, música, etc.) concentrando todos los datos en uno o dos ficheros bien 
grandes. Si quisiera eliminar parte del contenido, el cracker deberá repasar la estructura del 
fichero íntegramente, lo que, debido a su tamaño, supone una tarea de mayor envergadura 
a que si estuviesen los datos repartidos en varios ficheros pequeños, que suele ser lo más 
habitual. Esta protección se ha empleado con juegos tales como Quake 3 o StarCraft. 


Esta técnica se empleaba más en el pasado, cuando muchos juegos se copiaban 
directamente al disco duro, cuyo tamaño no era entonces tan grande (como se mencionó 
anteriormente). Con los bajísimos precios que hoy en día tienen los discos vírgenes y con 
lo que se venden, sólo unos verdaderos entusiastas protegen los programas de esta manera. 
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ERRORES FICTICIOS DE SOFTWARE Y OTRAS MANIPULACIONES 
EN EL PROCESO DE FABRICACIÓN DE LOS CDs 


Esta técnica contra la copia de los CDs se emplea actualmente por la inmensa 
mayoría de las protecciones comerciales. Se basa en la comprobación deliberada (y no 
física) de errores y otras características identificativas (firmar digitales, etc.) de los CDs, 
bien difíciles de realizar que, lo más importante, exigen mucho tiempo si se pretende 
copiar el disco correctamente. Estas características especiales antipirata se utilizan 
frecuentemente para calcular una clave empleada por un compresor o codificador tipo PE, 
con el que a menudo se combina este método de protección. 


Para producir una copia exacta (clonar), el CD-ROM debe cumplir varias 
condiciones, entre ellas, la normativa RAW-DAO 96 (que define la capacidad de lectura y 
escritura de todos los canales de subcódigo). El CD-ROM más extendido con estas 
características es el TEAC CD-W524. También se pueden encontrar el PRETOR PX- 
W2410A y el Lite-On LTR-24102B. 


La situación difiere mucho entre los distintos tipos de protección. El tema será 
tratado con mayor detalle en la siguiente sección, donde se estudiarán las protecciones una 
por una. 


Protecciones comerciales 


No lleva tiempo decidir qué protecciones deben figurar en esta sección. En teoría, 
deberían señalarse todas las protecciones desarrolladas con fines comerciales. Por otro 
lado, no parecería muy sensato incluir aquí todos los programas de protección de código 
compartido. Razón por la que solamente aparecerán los productos de protección y más 
extendidos, creados, con algunas excepciones, por grandes empresas y diseñados para 
proteger el software de manera compleja. Ello excluye algunos codificadores/compresores 
comunes de tipo PE (véase el capítulo 7), que se tratarán posteriormente. 


Resulta estéril describir y analizar todas las protecciones comerciales con detalle. 
No hay ni una (entre las creadas por ahora) que haya perdurado lo suficiente, y en Internet 
se pueden encontrar cracks genéricos para la mayoría de ellas. Me remitiré a presentar una 
breve descripción de los errores más frecuentes que los desarrolladores han cometido en 
cada uno de los casos. 


La lista comienza con las protecciones contra la copia de CDs. Esta lista comprende 
la mayoría de productos comerciales más y menos conocidos, antiguos y modernos, 
dedicados a proteger los datos de los CDs (algunos de los cuales también funcionan con 
DVDs): 
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Nombre comercial: Nombre de la empresa: 

Alcatraz KDG 

CD-Cops LINK Data Security Spinner Software 

CopyLok Pan Technology Limited Toolex 
International N.V. 

CDLock CrypKey 

DBB Effnet 

DiscGuard TTR Technologies Inc. 

FADE Codemasters 

LaserLock MLS LaserLock International 

LockBlocks Dinamic Multimedia 

Phenoprotect Codecult 

ProtectCD VOB 

Ring PROTECH ED-CONTRTIVE 

Roxxe Electronic Publishing Association LLC 

SafeDisc C-Dilla Macrovision Corporation 

SafeCast C-Dilla Macrovision Corporation 

SecuROM Sony 

Star Force Protection Technology Co. 

TAGES Thomson £ MPO 

The Bongle Hide $: Seek Technologies 

The Copy-Protected CD Hide 4 Seek Technologies 


Puesto que todas estas protecciones se basan prácticamente en el mismo principio y 
resultan idénticas en muchos aspectos, no sería práctico estudiarlas una a una por separado, 
Se describirán las más conocidas, en las cuales se han basado las demás. 


SAFEDISC 


Esta protección antipirata de C-Dilla no es nueva en este mercado. Explota la bien 
probada combinación de un codificador tipo PE (véase el capítulo 7) y una protección 
contra la copia creando un vínculo entre ambas. La segunda se basa por un lado, en el gran 
número de errores practicados en el CD (unos 20.000) y, por otro, en la presencia de una 
firma digital especial en el disco original, empleada para cifrar y descifrar el programa. 
Estas propiedades resultan muy robustas y, lo más importante, conlleva una gran cantidad 
de tiempo copiar un disco con precisión, con lo que realizar copias idénticas un disco se 
convierte en una tarea extremadamente difícil. Existe un descodificador genérico para la 
versión anterior de SafeDisc en Internet con el que el programa puede ejecutarse inclusive 
desde una copia de seguridad sin estas defensas. Además, se ha detectado un error en el 
algoritmo de cifrado, gracias al cual se puede descifrar un fichero mediante un ataque 
masivo en un período de tiempo que oscila desde unos segundos a pocos minutos. Así, se 
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evita la necesidad de disponer del CD original al suprimir la protección. A pesar de los 
problemas mencionados y de sus constantes actualizaciones, SafeDisc constituye una de 
las protecciones más extendidas en todo el mundo y la incluyen la mayoría de los juegos. 
No existe en el mercado ningún producto comercial que pueda competir con ella. Las 
empresas que la utilizan son conscientes de que no evitarán la difusión ilegal de su 
software, pero al menos restringirán la copia del CD entre los usuarios comunes, 


Editor EN Empresa de grabación Duplicador 


El contenido queda cifrado en ] 
Genera discos con 


un disco maestro con las Un grabador láser E 186 
herramientas de SafeDisc añade una firma digital firma digital y 
== al disco maestro 74 contenido cifrado 


Consumidor => 


CD Original 
La instrucción de autentificación 
localiza la firma digital y reproduce 


Ordenador con CD-ROM 


el disco 
Copia de CD 
La instrucción de autentificación no 
Intento de localiza la firma digital y evita la 
copia reproducción del disco 


Figura 1-13. Tecnología de fabricación de CDs protegidos con SafeDisc 
SECUROM 


En lo que este autor alcanza a conocer, este producto de Sony fue la primera 
protección contra la copia de CDs que se empleó en grandes cantidades. SecuROM 
representa una versión “light” de SafeDisc, en la que en verdad esté inspirado. Aunque se 
haya actualizado constantemente, ha quedado ya obsoleto y no representa gran dificultad 
anular la protección que brinda. 


PROTECTCD 


El último producto contra la copia de CDs basado en un codificador PE que se 
discutirá en esta sección se denomina ProtectCD, de VOB. Es el miembro más reciente de 
la familia de productos centrados principalmente en el software de juegos. A semejanza de 
sus hermanos mayores SafeDisc y SecuROM, no aporta ninguna tecnología radicalmente 
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nueva. Para quien pueda enfrentarse a los dos sistemas anteriores, ProtectCD no constituye 
ningún problema. 


Así llegamos al final de esta breve lista de los productos comerciales mejor 
conocidos y más extendidos para dotar al software de una protección contra la copia de 
CDs. Muchos no figuran en esta lista por haber quedado anticuados y resultar muy fáciles 
de anular (como LaserLock). 


Llega ahora el momento de considerar otros productos comerciales de distinta 
categoría. Se basan en la modificación del software para conseguir su protección (por 
ejemplo, versiones de duración limitada, protección mediante número de serie, etc.). 


ARMADILLO SOFTWARE PROTECTION SYSTEM 


bp System, Basic Teal Editor 


Bl! aaa 


? Project Settings: 


No project loaded, Select Open 


Project 1D and Version 
Files to Protect 
Language 

Splash Screen 1 


€ Enhanced SofICE Detection 
(% Standard SOÑICE Detection 
€ No SoÑiCE Detection 


Protection Options 
Backup Key Options 
Compression Options 


Data-After-Program Options (Pro) 
Interception Options 

Std Hardware Locking (Pro) 

Enh Hardware Locking (Pro) 
Other Options 

Certificates 


[Select the SONICE detection option to use here. 


Figura 1-14. Armadillo y sus propiedades 


Las versiones anteriores de este producto incurrían en una serie de errores que, dada 
la protección basada en el cifrado de un fichero PE, podían considerarse muy serios. 
Exponer los algoritmos de antidepuración (“antidebugging”, en inglés), tan pésimamente 
ocultos que los vuelve detectables casi inmediatamente (para ser más precisos, no se han 
ocultado en absoluto), convierte al propio bucle de descodificación en el único obstáculo 
real. Primero descifta el programa y a continuación invoca la función API CreateProcess, 
que crea un nuevo hilo para el programa protegido. El hilo se crea dejando el parámetro en 
suspenso (para permitir el descifrado de otras partes del programa), lo que implica que el 
programa se arranca nada más invocar la función API ResumeThread. Ello facilita 
muchísimo la tarea al cracker: sólo necesita establecer el punto de corte en esta función y 
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guardar el contenido del hilo (el programa completamente descifrado) de la memoria al 
disco. Puesto que no existe ningún otro mecanismo de protección, el fichero no necesita 
modificarse posteriormente, resulta plenamente funcional y desprotegido —eso, si su 
estado anterior pudiera considerarse “protegido”-—. Puede que un principiante no pueda 
anular esta protección, pero no es más que un entretenimiento para un experto. 


Muchos de los errores se han corregido en las nuevas versiones del producto. Se ha 
mejorado claramente el bucle de descodificación y los propios algoritmos de 
antidepuración. Con estas medidas, y aunque continúe resultando fácilmente detectable, 
aún puede obstaculizar la labor de los crackers, incluso los más expertos. A pesar de todo, 
existen herramientas de cracking capaces de suprimir automática e integramente esta 
protección en un abrir y cerrar de ojos. 


ASPROTECT 


Su acertada combinación de un compresor PE y de varias excelentes funciones de 
protección, sitúan a este producto entre los más destacados en su género. La compresión de 
ASProtect se basa en un algoritmo PE que constituyó el precedente de este tipo de 
protecciones y que en su momento se denominó ASPack. Permite alcanzar niveles de 
compresión muy altos. 


Pes AsProtect v1.2 [Untitled] 
Project Help 


Application info [ Registration keys | Trial info | Protect | 


Compression options Protection oplións | 


(4 Protect resources Y Antidebugger protection 

l” Preserve extra data [Debugger detected - please close it dawn and restart! 

1 Use max. compression [Vindons NT users: Please note that having the 

[data Section's name | 


Y Checksum protection 


A 


Y Create backup copy [BAK-file) ¡Please run a virus-check, then reínstall the application. 


Auto run after loading 


17 Esitwhen done 


Figura 1-15, ASProtect llama la atención por su buena organización 
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La protección incluye varias medidas contra el volcado de datos, lo que dificulta 
enormemente el volcado del programa descifrado, especialmente con ProcDump 
(programa que se describirá en el capítulo 5). Al poner el autor especial cuidado en el 
cifrado de la tabla de importaciones original (véase el capítulo 7), el cracker potencial 
deberá volcar el fichero de cifrado y la tabla de importaciones por separado para 
posteriormente integrarlas. Puesto que los algoritmos antidepuración no son lo 
suficientemente sofisticados, el proceso de descompresión manual no supone una gran 
incomodidad. Si bien algo más difícil de lo normal, a un cracker con veteranía no le debe 
asustar en absoluto. 


La mayor virtud de ASProtect consiste en la protección que confiere a los productos 
de código compartido cuyas versiones no registradas carecen de ciertas funciones. 
ASProtect cifra estas funciones según el número de serie (o clave de activación — 
denomínese como se desee—) de manera que quedan deshabilitadas hasta que el producto 
protegido se registre. Este método se describió al comienzo del primer capítulo, sabiendo 
lo que allí se comentó, resulta prácticamente inútil hallar (mediante un depurador) el 
número de serie exigido. Gracias al algoritmo de cifrado empleado, tampoco valen de nada 
los ataques masivos; e incluso si el cracker pudiera descomprimir manualmente el fichero, 
sin conocer la clave de registro no le valdría de nada. 


SALESAGENT 


El lector puede haberse encontrado con esta protección sin saberlo. Muy típica de 
los productos en demo, donde se limita el uso del programa protegido a cierto período de 
tiempo. También denominados en inglés “try and buy”, puesto que al arrancar el programa 
protegido se presenta un cuadro de diálogo (que, sin embargo, se denomina de diversas 
maneras) con la posibilidad de comprar el producto a través de Internet y de probarlo 
(suponiendo que no se haya consumido ya el período de prueba). 


Esta protección se ha utilizado, por poner algunos ejemplos, en los productos de 
Symantec (Norton Utilities, Norton Antivirus) y en prácticamente todos los de 
Macromedia. El código de programa no se cifra en modo alguno, no se valida la integridad 
de la memoria, sólo la integridad de los datos de los ficheros. Todo lo que el cracker ha de 
hacer es crear un cargador (véase el capítulo 6) o deshabilitar la propia rutina de 
comprobación, cuya identificación es cuestión de unos pocos minutos. 


VBOX 


VBOX parece ser el programa de protección más antiguo, junto con SalesAgent, 
basado en la duración limitada de los productos. VBox utiliza el cifrado de ficheros, cierto 
número de comprobaciones de integridad, y resulta bastante sofisticado en términos 
generales. Desgraciadamente, los desarrolladores no consideraron la peor arma contra el 
descifrado de ficheros, esto es, el volcado de datos. Puesto que un fichero descifrado puede 
guardarse con facilidad de la memoria a un disco, esta protección resulta muy fácil de 
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superar, Se ha venido actualizando continuamente, lo que puede comprobarse a partir del 
gran número de versiones (las primeras solían denominarse Timelock), y constituye una 
solución excelente para la versiones de los programas en demo. 


Programas en Visual Basic 


Uno de los mayores inconvenientes de los programas de Visual Basic radica 
en que el autor a duras penas controla el resultado final del código (tras la 
compilación). Ello se debe a que en su mayor parte hace referencias y llamadas a DLL 
de Visual Basic, generalmente a las de tipo msbvmXX.dll (donde XX indica la versión 
del lenguaje). 


Los crackers no son muy aficionados a estos programas ya que resulta difícil 
orientarse y el código resulta confuso; lo que le obliga a invertir la mayor parte del 
tiempo en el código de la DLL. No obstante, la tarea se simplifica muchísimo 
empleando programas de depuración para Visual Basic (como SmartCheck o 
VBDebugger), lo que reduciría a pocos minutos la tarea de anular la mayoría de las 
protecciones. 


No es en absoluto cierto que bloquear las protecciones de estos programas sea 
necesariamente más fácil que con otros lenguajes de programación. Que el código del 
algoritmo de protección en sí forme parte de alguna clase de librería que resulte 
inaccesible al programador supone una desventaja en buena parte de las ocasiones, 
pero no siempre sucede así. 


Anular estos programas con frecuencia exige encontrar la función específica 
invocada por el programa de la librería. Bien se pudiera pensar que esto constituye una 
ventaja, puesto que estas funciones no están bien documentadas como las API, por 
ejemplo. 


Aunque pudiera ser cierto, los crackers no pierden el tiempo y compilan 
manuales de referencia para las funciones de todo tipo. Por esta razón, ya se conoce en 
un buen número de funciones de muy diversa índole. Como entre las más destacadas 
figuran las funciones que comparan números o cadenas de caracteres (números de 
serie, contraseñas, etc.), el cracker puede calcular los números necesarios en cuestión 
de segundos sin tener que analizar el código de programa. No tiene más que establecer 
el punto de corte en la función pertinente y leer el número requerido, 


En la práctica, el cracker contemplará todas las funciones que se hayan podido 
emplear y elegirá las más probables, el éxito estaría casi asegurado. 


También juega un papel importante la versión del lenguaje. Al aumentar el 
número de funciones con las versiones superiores, las posibilidades del programador 
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también son mayores (como podrá tal vez elegir una función poco conocida), y así 
disminuyen las facilidades del cracker. 


Visual Basic no resulta idóneo para desarrollar aplicaciones “seguras”, debiera 
descartarse para codificar software de protección de calidad. Puesto que hay donde 
elegir, se puede escoger cualquier otro lenguaje —Ensamblador si fuera posible—. Si 
se optase por Visual Basic como herramienta de programación, deberá renunciarse a 
un buen mecanismo de protección. El lenguaje no fue diseñado con ese objetivo. En 
todo caso, la decisión depende del programador. 


Para ilustrar esta afirmación, se reseñan a continuación los tres métodos más 
conocidos para comparar dos valores en Visual Basic. Resultan muy útiles para 
calcular números de serie y contraseñas de todo tipo. 


COMPARACIÓN DE CADENAS DE CARACTERES 


Este método constituye la forma más sencilla de comparación. Resulta facilísimo 
hallar el número buscado. 


If "Correct_password"” = "Keyed_in password” then 
GoTo registration _succeeded 

Else 

GoTo error 

End if 


Posibles puntos de corte 


_ vbastrcomp or __vbastremp (STRing COMpare) 


Búsquense combinaciones concretas de los siguientes bytes: 
56,57,8b,7c,24,10,8b,74,24,0c,8b,4c,24,14,33,c0,3,66,a7 (cuando se definan puntos de 
corte con VB6, el nombre de la función debe procederse con msvbvmó0!, por ejemplo, 
bpx msvbvm60! _ vbastrcomp). 


COMPARACIÓN VARIABLE (TIPO DE DATOS VARIABLE) 


La ventaja de este método de comparación reside en evitar el uso de las funciones 
conocidas anteriormente mencionadas. 


A E 
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Dim Correct As Variant, keyed_ in As Variant 
Correct = Correct_password 

keyed_in = Textl.Text 

If Correct = keyed_in Then 

GoTo registration succeeded 

Else 

GoTo error 

End If 


Posibles puntos de corte 


—vbavartsteq (VARiant TeST EQual) 
COMPARACIÓN VARIABLE (TIPO DE DATOS LARGO) 


Este método resulta casi idéntico al anterior, la única diferencia radica en el tipo 
de datos utilizados. Su ventaja reside en que la rutina de comparación no está incluida en 
ninguna librería, sino en el propio programa y por lo tanto no se puede utilizar ningún 
punto de corte específico. Por el tipo de datos utilizado, la contraseña sólo puede consistir 
en números. 


Dim Correct As Long, keyed_in As Long 
Correct = 12345 

keyed_in = Text1.Text 

If Correct = keyed_in Then 

GoTo registration succeeded 

Else 

GoTo error 

End If 


En vez del tipo de datos “Long”, se puede utilizar “Single”, “Double”, “Integer”, 
“Byte” o “Currency”. 
Aún quedan más funciones. 
CONVERSIÓN DEL TIPO DE DATOS 


A continuación se indican algunas de las funciones utilizadas para convertir datos 
de distinto tipo: 
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String to Byte or Integer: _ vbai2str 
String to Long: _ vbail4str 

String to Single: _ vbar4str 

String to Double: _ vbar8str 


String to Currency: VarCyFromsStr 
Integer to String: VarBstrFromI2 


TRANSFERENCIA DE DATOS 


La transferencia de datos en memoria se realiza mediante una de las siguientes 
funciones: 


String to memory: _ vbaStrCopy 
Variant to memory: _ vbaVarCopy nebo _ vbaVarMove 


OPERACIONES MATEMÁTICAS 


Existe cierto número de operaciones matemáticas empleadas para calcular 
contraseñas y números de serie. A continuación se enumera una lista con las funciones más 
utilizadas con este fin. 


Suma: _vbavaradd 
Sustracción: — vbavarsub 
Multiplicación: —_vbavarmul 
División: _ vbavaridiv 
XOR: _ vbavarxor 


MISCELÁNEA 


Esta lista finalizará señalando otras funciones útiles: 


__vbavarfornext —con bucles de 'For' y 'Next' 
__vbastrvarval — para obtener un valor en cierta posición de la cadena 
rtcMsgBox — MessageBox, muy útil. 


Otras vulnerabilidades de las protecciones actuales 


El primer paso de un cracker que intente anular la protección de un programa 
concreto consiste en su identificación. Resulta inviable con ficheros voluminosos examinar 
una por una las líneas del código del programa con objeto de buscar el algoritmo de 
protección. Razón por la que algunos crackers han diseñado distintos métodos para 
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localizarlos e identificarlos con exactitud tan rápidamente como sea posible. Estos métodos 
abundan, los más eficaces se describirán en los capítulos 2 y 3. Suelen utilizar servicios de 
desensamblaje y depuración. Lo que explica las referencias a las funciones API más 
frecuentemente utilizadas en las protecciones mencionadas anteriormente. A continuación 
se podrá comprobar lo fácil que resulta identificar la protección sabiendo las funciones 
(entre otras cosas) empleadas en ella. Nunca se insistirá lo suficiente para evitar emplear 
funciones API al codificar la protección de un programa. Estas funciones constituyen el 
punto de entrada más frecuente para que el cracker penetre en el programa y le conduzca al 
mecanismo de protección. El programador deberá responder a esta crucial cuestión al 
desarrollar una protección: ¿cómo se procederá cuando se cree un número de registro 
incorrecto, cuando haya transcurrido la duración de un programa en prueba o cuando se 
detecte un intento de anular el programa de protección, etc.? 


Apenas unas pocas personas afrontan este problema crucial a pesar de que 
constituye la piedra angular de la protección del software, y que por tanto, puede 
causar efectos en la seguridad inimaginables. Existen actualmente protecciones cuyos 
desarrolladores no se han privado de utilizar funciones API bien conocidas, como 
MessageBoxA, que informa a los usuarios, por ejemplo, sobre si el número 
introducido es o no correcto; todo ello hace inútil la protección. Hay programadores 
que ignoran que la protección debe abarcar el modo en el que se informa al usuario. 
Obviamente la ventana que informa al usuario debe ubicarse en algún sitio e invocarse 
desde algún otro. No hay mejor lugar que en las inmediaciones del algoritmo crucial 
para su existencia, esto es, el algoritmo de protección. 


La mayor parte de los programas de código compartido recuerdan de varias 
maneras al usuario la necesidad de registrar el programa. Quizá la más frecuente sean 
los cuadros de advertencia —las denominadas, en inglés, pantallas NAG (“to nag': 
fastidiar, molestar) —. Todos conocemos las inoportunas ventanas que nos recuerdan 
que estamos utilizando una versión no registrada del programa. Su papel en la 
protección no es baladí. Consiste en molestar al usuario hasta el punto que registre o 
compre el producto original. 


La situación es idéntica a la descrita en la sección anterior. Se utilizan 
funciones API muy conocidas para la creación de ventanas; incluso cuando los 
programadores sean cuidadosos, aún hay otros métodos que pueden aplicarse a las 
ventanas (véase el capítulo 2). No se debe crear ninguna ventana, diálogo, ni nada 
similar que no sea absolutamente necesario. ¿Acaso no basta con informar al usuario 
sobre el registro del programa en la ventana “Acerca de ...”? 


CRA-MA CAPÍTULO 1: MÉTODOS DE PROTECCIÓN Y SUS PUNTOS DÉBILES _ 55 


¡TERED COPY! 29) 
This copy ol Vital Tuntables ls UNREGISTERED! 


UNREGISTERED you say? Thal's tight the copy ol Vitual > 
Tumtables (/TT) that you hold in your hands is UNREGISTEREDI 


==Ok. Sois UNREGISTERED . Somhat?= 


a E 
| > Thisis a "limited" copy. You can mis for only 40 minutes! In the 
ae ve idas 

some 


ted version, you have an unlimited amount of E 
> M you use ¡lor more than 21 days.. 11'S ILLEGAL S 
depriving a poor 20 year college student (namely mysell) of 
Sd o bell REGISTERING! 

the benelis ol REGISTERING) 


| 
4 
> Youre 
E 


=A completely UNLOCKED version of InterCode For Windows. 
That means bye bye 40 minute limit and bye bye NAG SCREENS! 
1 «free and reduced price uporades (50%) for future releases 
e My never ending gratitude. Thank you. Thank you.. 


5 So what ARE the benefi of registering? <= J 


How do you acquíe all these great benefits? You REGISTER of coursel 
Complete he ORDER.FAM document and send it back, "You will Ihen 
teceive via VOICE or EMAIL a special code to unlock this program and 

gain access lo some of its CODLEST features! 5 


Remember. You may use this program for up lo 21 days. Añter lhal.. rs 
ILLEGAL 


Continue wih his UNREGISTERED version. ] 


Figura 1-16. Cuadro de diálogo con el que se promete al usuario muchas más 
funcionalidades si llega a registrarse 


Una última recomendación: una de las características más importantes del 
algoritmo de protección, a menudo infravalorada, consiste en la respuesta que dé a 
diversas situaciones. Téngase siempre en cuenta la existencia de algún otro método 
difícil de identificar que pudiera utilizarse para informar al usuario en vez de un 
cuadro de diálogo o una ventana. Más cierto aún si cabe referido a las partes críticas 
de un algoritmo de protección. Varias protecciones actuales reaccionan deteniendo el 
programa o bloqueándose, por ejemplo, al detectar un programa de depuración en 
funcionamiento. Si bien no constituye el mejor método en lo que al usuario concierne, 
puesto que ignora por qué el programa se bloquea, sí representa probablemente el 
mejor método en lo que respecta a seguimiento y seguridad. Una cosa es el 
seguimiento de la actividad para vulnerar un programa y otra bien distinta, la respuesta 
a dicha actividad. Este libro dará cuenta de muchos algoritmos de detección junto a 
otras medidas de protección (algunas veces conjuntamente). 


Otro problema de seguridad hallado en varias protecciones actuales consiste en 
un uso descuidado de las cadenas de caracteres. Como se verá en el tercer capítulo 
dedicado al desensamblaje, resulta muy sencillo encontrar la ubicación del algoritmo 
de protección interrogando a las cadenas empleadas por el programa. Considérese por 
un momento si resulta absolutamente necesario que el programa guarde las cadenas 
“registro satisfactorio” o “número de serie incorrecto”. Este problema se puede 
acometer de diversas maneras según se describirá en el capítulo tercero, 
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Antes, he aquí una lista con las funciones APLI relativas a ventanas: 


BitBlt 
La función BitBlt realiza una transferencia en bloque de los bits de 


color correspondientes a un rectángulo de píxeles desde el dispositivo 
contextual (DC) origen indicado a otro de destino, 


BOOL BitBIt( 
HDC hdcDest, // manejador al DC de destino 


int nXDest, // coordinadas X del ángulo superior izquierdo de 
//destino 


int nYDest, // coordinadas Y del ángulo superior izquierdo de 
//destino 


int nWidth, // anchura del rectángulo de destino 
int nHeight, // altura del rectángulo de destino 
HDC hdesSrc, // manejador al DC 


int nXSrc, // coordinadas X del ángulo superior izquierdo de 
/lorigen 


intnYSre, //// coordinadas Y del ángulo superior izquierdo de 
/lorigen 


DWORD dwRop // código de operación raster 


): 


Valores obtenidos 


De tener éxito, la función obtiene un valor distinto de cero. 
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De no tener éxito, la función obtiene un valor igual a cero. 


Windows NT/2000/XP: Si se deseara mayor información sobre el 
error, invóquese GetLastError. 


Create Window 


La función Create Window crea una ventana solapada, emergente O 
esclava (“overlapped”, “pop-up”, O “child?). Determina la clase, título, 
estilo, y (opcionalmente) la posición inicial y tamaño de la ventana. 
La función también define, si existiera, la ventana maestra O 
propietaria, y el menú de la ventana. 


Si se desearan utilizar estilos de ventana complementarios distintos a 
éstos, utilícese la función Create WindowEx. 


HWND Create Window( 
LPCTSTR IpClassName, // nombre de clase 
LPCTSTR IpWindowName, // nombre de ventana 


DWORD dwStyle, // estilo de ventana 


int Xx, // posición horizontal de la ventana 
int y, // posición vertical de la ventana 
int nWidth, // anchura de la ventana 

int nHeight, // altura de la ventana 


HWND hWndParent, — // manejador de la ventana maestra 
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HMENU hMenu, // manejador de menu o identificador de la 
/Iventana esclava 


HINSTANCE hinstance, // manejador a la ocurrencia de la 
// aplicación 


LPVOID IpParam // datos de creación de la ventana 


d 


Valores obtenidos 


De tener éxito, la función obtiene un manejador de ventana nueva. 


De no tener éxito, la función obtiene valor NULL. Si se deseara 
mayor información sobre el error, invóquese GetLastError. 


Cuando esta función falla, lo suele hacer por las siguientes razones: 
- un valor de parámetro incorrecto 

- la clase del sistema la registró un módulo distinto 

- está instalado el enlace WH_CBT y devuelve un código de error 


- el procedimiento de ventana falla por WM_CREATE o 
WM_NCCREATE 


Create WindowEx / Create WindowExA / Create WindowExW 


La función Create WindowEx crea una ventana solapada, emergente o 
esclava (“overlapped”, “pop-up”, o *child”) de modo extendido; por 
otra parte, esta función resulta idéntica a Create Window. Si se deseara 
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ES 


mayor información sobre cómo crear una ventana y una descripción 
completa de otros parámetros para CreateWindowEx, véase 
Create Window. 


HWND Create WindowEx( 
DWORD dwExStyle,  // estilo extendido de ventana 
LPCTSTR IpClassName, // nombre de clase 
LPCTSTR IpWindowName, // nombre de ventana 


DWORD dwsStyle, // estilo de ventana 


intx, // posición horizontal de la ventana 
int y, // posición vertical de la ventana 
int nWidth, // anchura de la ventana 

int nHeight, // altura de la ventana 


HWND hWndParent, — // manejador de la ventana maestra 


HMENU hMenu, // manejador de menú o identificador de la 
//ventana esclava 


HINSTANCE hinstance, // manejador a la ocurrencia de la 
/laplicación 


LPVOID IpParam // datos de creación de la ventana 


OS 


Valores obtenidos 


De tener éxito, la función obtiene un manejador de ventana nueva. 
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De no tener éxito, la función obtiene valor NULL. Si se deseara 
mayor información sobre el error, invóquese GetLastError. 


Cuando esta función falla, lo suele hacer por las siguientes razones: 
- un valor de parámetro incorrecto 

- la clase del sistema la registró un módulo distinto 

- está instalado el enlace WH_CBT y devuelve un código de error 


- el procedimiento de ventana falla por WM_CREATE o 
WM_NCCREATE 


SendMessage / SendMessageA / SendMessageW 


La función SendMessage envía el mensaje indicado a una o varias 
ventanas. Invoca al procedimiento de ventana según la ventana 
indicada y no devuelve el control hasta que el procedimiento de 
ventana haya procesado el mensaje. 


Si se deseara enviar un mensaje y obtener el control inmediatamente, 
utilícense las funciones SendMessageCallback o SendNotifyMessage. 
Para enviar un mensaje a un hilo con una cola de mensajes y obtener 
el control inmediatamente, véanse las funciones PostMessage o 
PostThreadMessage. 


LRESULT SendMessage( 
HWND hWnd,  //manejador de la ventana de destino 
UINT Msg,  //mensaje 


WPARAM wParam, // primer parámetro del mensaje 


CRA-MA 
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LPARAM IParam- // segundo parámetro del mensaje 


); 


Valores obtenidos 


El valor obtenido indica el resultado del procesamiento del mensaje; 
dependerá del mensaje enviado. 


ShowWindow 


La función ShowWindow define el estado de visibilidad de la ventana 
indicada. 


BOOL ShowWindow( 
HWND hWnd, — // manejador de ventana 


intnCmdShow // estado de visibilidad 


) 


Valores obtenidos 


Si la ventana ya resultaba visible anteriormente, el valor obtenido será 
distinto de cero. 


Si la ventana estaba oculta anteriormente, el valor obtenido será igual 
a cero. 
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UpdateWindow 


La función Update Window actualiza el área cliente de la ventana 
indicada enviando un mensaje WM_PAINT a la ventana si su región 
de actualización no estuviera vacía. La función envía un mensaje 
WM_PAINT directamente al procedimiento de ventana de la ventana 
indicada saltándose la cola de aplicación. Si la región de actualización 
estuviera vacía, no se enviaría ningún mensaje. 


BOOL Update Window( 


HWND hWnd // manejador de ventana 


) 


Valores obtenidos 


De tener éxito, la función obtiene un valor distinto de cero. 


De no tener éxito, la función obtiene un valor igual a cero, 


Windows NT/2000/XP: si se deseara mayor información sobre el 
error, invóquese GetLastError. 


Por último, otra función imprescindible: 
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HMEMCPY 


Esta función API utiliza memoria (RAM) para manejar los datos, 

| normalmente caracteres en una cadena. Por esta razón resulta muy útil 
para penetrar en programas que emplean protecciones basadas en 
cadenas de caracteres —números de serie, contraseñas, etc.—, No se 
suele utilizar para penetrar en programas como Delphi o VisualBasic, 
que no trabajan con las funciones API estándar GetWindowTextA ni 
GetDlgltemTextA para leer el texto definido por el usuario. Se podrá 
estudiar con más detalle esta función en el capítulo 9, donde se 
incluyen ejemplos prácticos. 


CONCLUSIÓN 


En este capítulo se han repasado tanto las técnicas actuales de protección de 
| software como sus puntos débiles. A su luz, los desarrolladores podrán plantearse qué tipo 
| de errores han cometido y qué soluciones aplicar. Precisamente éste es el objetivo de los 
capítulos siguientes. 


CAPÍTULO 2 


PROTECCIÓN CONTRA LOS 
PROGRAMAS DE DEPURACIÓN 


Resulta prácticamente imprescindible para cualquier programador actual disponer 
de un buen depurador, Le permitirá encontrar prácticamente cualquier detalle de un 
programa en cuestión de segundos para poder examinarlo y modificarlo, así como buscar 
posibles errores. Desgraciadamente, un depurador puede utilizarse no sólo para optimizar 
el propio código, sino el software de otros autores. Auxiliado con un buen conocimiento de 
ensamblador, un depurador normal puede convertirse en un arma peligrosa. No es preciso 
recordar a quienes conozcan el potencial real de los mejores depuradores que constituye un 
tipo de software vital y de la mayor importancia para el cracker. El lector lo podrá 
comprobar a lo largo de este libro por sí mismo. Merece la pena, por tanto, intentar 
obstaculizar la utilización de depuradores, 


Nunca deberán considerarse los algoritmos antidepuración el fundamento de la 
protección de un programa. Muchos expertos afirman con razón que en vez de crear 
programas antidepuradores, los desarrolladores deberían invertir más tiempo diseñando el 
sistema de protección adecuado. El utilizar algoritmos antidepuración puede ser una buena 
idea, pero deben jugar un papel complementario en la protección. 


En este libro no se recoge una lista completa de todos los algoritmos 
antidepuradores que, además, se pueden encontrar en Internet. Y no porque haya 
demasiados, sino porque algunos se han quedado anticuados y resultan inútiles —la 


66 CRACKING SIN SECRETOS ORA-MA 


mayoría sencillamente no funcionan—. Por eso, la lista aquí presentada contiene los 
algoritmos que aún se pueden utilizar con distinta suerte o bien porque debido a su fama 
resultaba obligatorio reseñar. 


DEPURADORES MÁS HABITUALES 


SoftICE 


El número de depuradores actualmente disponible es extraordinario, pero ni uno 
solo de ellos puede utilizarse para el cracking como éste. Habrá muchos donde elegir, pero 
rey sólo hay uno. No resulta exagerado afirmar que lo utilizan el 99,9% de los crackers de 
todo el mundo. Sus muchos años de presencia en el mercado internacional del software le 
han deparado una posición imbatible, que le convierten prácticamente en la única opción 
para quienes quieran realmente programar con seriedad. Gracias a estas propiedades y 
virtudes, este software goza de gran popularidad especialmente entre los crackers. Nadie 
que tenga siquiera un interés secundario en el cracking podrá desenvolverse sin esta 
herramienta. 


TRW constituye otro depurador de gran calidad. Aunque sus autores insistan en que 
supera a SoftiICE en muchos aspectos, la popularidad de este programa sigue sin superarse, 


USO ELEMENTAL DE SOFTICE 


Ser capaz de trabajar con este soberbio programa forma parte de las aptitudes 
esenciales no sólo de cualquier cracker, sino de todo buen programador. Veamos al menos 
los mandatos fundamentales de SoftICE; el resto podrá encontrarse en la sección de 
referencia del libro y en la magnífica ayuda del programa. 


Configuración del programa 


Antes de utilizarse por vez primera, SoftICE debe quedar configurado 
correctamente. El paso más importante en el proceso de configuración consiste en cargar 
las funciones exportadas por las DLLs pertinentes para que los puntos de corte puedan 
trabajar con estas funciones. En nuestro caso concreto, los puntos de corte van a apuntar la 
mayoría de las veces a funciones API, lo que nos obliga a cargar sus dos DLLs más 
importantes: kernel32.dll y user32,dll. 


Únicamente los usuarios de Windows 9x/Me precisan realizar esta operación puesto 
que la versión de SoftICE para Windows NT/2000/XP carga las dos librerías 
automáticamente. El programa “Symbol Loader” (en castellano, cargador de símbolos, 
incluido en la instalación de SoftICE, puede cargar también ambas librerías, pero resulta 
mucho más rápida la alternativa manual: edítese el fichero winice.dat ubicado en el 
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directorio de instalación de SoftICE. Se puede abrir con notepad; búsquese la sección 
siguiente: 


¡**e***Examples of export symbols that can be included for 
Windows 95 *****; 

Change the path to the appropriate drive and directory 
¡EXP=c:windows1systemlkernel32.d11 
¡EXP=c:windows|systemluser32.d11 
¡EXP=c:IwindowsYsystemigdi32.d11 


Los puntos y coma al principio de algunas líneas definen comentarios que no se 
procesarán (al igual que el mandato REM en un fichero BAT de MS-DOS). Suprímase el 
punto y coma correspondiente y, si fuera necesario, modifíquese el directorio para que 
señale a la librería correctamente para que las cargue y queden listas para su uso. Guárdese 
el fichero y rearránquese el ordenador para que el cambio tenga efecto. 


Se pueden añadir otras DLLs a voluntad cuyas funciones quieran emplearse como 
puntos de corte. Pongamos por caso que se desea depurar un programa en Visual Basic, 
será preciso entonces cargar el fichero msvbmXX.dll (donde XX indica la versión del 
lenguaje). 


El fichero winice.dat puede emplearse para otros usos también (deberá utilizarse 
“Symbol Loader” al no haber fichero winice.dat en Windows NT). Identifíquese la línea 
que comienza con INIT. Será algo parecido a: 


INIT=,X; 


Indica la línea de inicialización de SoftICE, esto es, una serie de mandatos que se 
ejecutan tras arrancar SoftICE. Gracias a ello, el usuario podrá adaptar SoftICE a sus 
necesidades. La siguiente línea de inicialización es utilizada por el autor: 


lines 60;wd 10;wc 30;wl;X; 


Los mandatos que empiezan por “w” gobiernan el modo en que se muestran las 
ventanas individuales; lines 60” hace que el programa trabaje en ventanas de 60 líneas. El 
mandato “X” resulta muy importante puesto que oculta SoftICE tras su inicialización de 
manera que no se muestre cada vez que se arranque. Resulta especialmente útil con 
Windows 9x/Me, donde SoftICE sólo se puede arrancar antes de que lo haya hecho el 
sistema completamente (de hecho, es SoftICE quien arranca primero para luego ejecutar 
Windows). 
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* NuMega SoftICE Symbol Loader 


File Edit Module Help 


CRE 


ebxdejaj el el el +] +] 


Figura 2-1. "Symbol Loader” de SoftICE y sus propiedades 


Conforme el lector se vaya haciendo familiar con SoftICE y sus mandatos, se verá 
capaz de configurarlo según sus necesidades. 


Esto es todo lo que se necesita saber de la configuración de esta herramienta única. 
De producirse algún problema (por ejemplo, con los dispositivos de tarjetas gráficas), 
acúdase a la documentación. 


Mandatos, funciones y controles básicos 


WINDOWS 


Lo más importante que se debe recordar es la combinación de teclas Ctrl+D para 
poder mostrar SoftICE (suponiendo que no se haya redefinido). Esta combinación de teclas 
tiene prioridad sobre las demás, no importa que ya se estén utilizando en una aplicación, 
juego o el mismo escritorio. Siempre conducirá a SoftICE, 


En la siguiente figura se muestra una representación esquemática de SoftlCE con 
etiquetas indicando sus ventanas básicas. Servirá de orientación al lector al utilizar el 
programa. 


O RA-MA 
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410070 80 10 Ba e 
paranaa $9 5S 


N1S4CABE E 
019 49 
8 


al 

PO 801 
n015 
Bar 


uosigned- int. 


Ventana de registro 


Ventanas locales 


unsigned int. los 


Flechas de desplazamiento 


Ventana de observación 


Ventana de datos 
itoRial 


Ventana de código 


Linea de mandatos 


Linea de ayuda 


Figura 2-2. Presentación de SoftICE. 


Ventana de registro (“Register window” en inglés): 


La ventana de registro muestra los nombres de todos los registros y sus valores 


mM 


el margen derecho también figuran ocho letras que representan atributos (en inglés, flags”) 
específicos del registro EFLAGS. Cuando el atributo queda definido se indica con el color 


azul. A continuación se describen los atributos: 


0) D I S Z A P € 
Overflow Direction  Interrupt Sign Zero Flag Auxiliary  Parity Carry 
Flag Flag Flag Flag (el flag Carry Flag Flag 
más 
utilizado) 
Flag 


Tanto los valores de los registros como de los atributos pueden evitarse mediante el 
mandato *'r valor de registro',o'r fl abreviatura de atributo”. 
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Ejemplo: 

e vr eax 1' — cambia el valor del registro EAX a 1 

e 'r fl z” —cambia el estado del atributo cero (zero flag) 
La ventana de registro se habilita y deshabilita con el mandato wr”. 
Ventana de datos (“Data window”, en inglés) 


Bajo la ventana de registro se halla la de datos (a no ser que se activen otras 
funciones más avanzadas, como la ventana de locales o de observación). Mediante el 
mandato 'd dirección" (se hará referencia a las direcciones de memoria en este libro 
por su valor hexadecimal), se podrá obtener el contenido de memoria de una dirección 
dada. También se podrán intercambiar las direcciones de memoria por los nombres de 
registro. Por ejemplo: con *d eax”, la ventana mostrará el contenido de memoria en la 
dirección correspondiente a este valor de registro. De igual manera, el contenido de la 
memoria se podrá editar con los mandatos: 'e ,eb ,ew ,ed ,es ,el” y * et”. 


El mandato *s dirección inicial 1 longitud 'cadena*' buscará 
cadenas en la memoria. Si la búsqueda terminase con éxito, la ventana de datos mostrará la 
dirección permitiendo continuar con la búsqueda mediante el mandato *s”. 


Ejemplo: 


e 's 0 1 123456 '“contraseña'' — buscará la cadena “contraseña” 
en el área de memoria  0-123456. El mandato  'wd 
número de líneas” modificará la ventana de datos así como su 
visualización. 


Ventana de código (*Code window”, en inglés) 


Bajo la ventana de datos se encuentra la ventana del código que se está depurando. 
Con FlO0 y FS se salta de una instrucción a otra; la única diferencia entre ambas radica en 
que con F8 SoftICE utiliza instrucciones CALL, mientras que con F10 no. Para recuperar 
el control desde las instrucciones CALL, o más precisamente, para detenerse tras procesar 
la siguiente instrucción RET, utilícese F12. 


Todas estas teclas representan mandatos que el usuario puede configurar a su 
discreción. Si se deseara más información sobre cómo realizar esta asignación, acúdase 
bien al fichero winice.dat (Windows 9X/Me) o bien al “Symbol Loader” (todas las 
plataformas Win32). 
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Ejemplo: 
“va 0040100” mostrará el texto siguiente: 
“XXXX:00401000 specify the requested instruction” 


Tras pulsar intro se presentará al usuario la oportunidad de editar la siguiente 
instrucción. Al pulsar intro de nuevo, en vez de editar una nueva instrucción, se 
pondrá fin a la edición. El mandato *wc número _de_líneas' maximizará O 
minimizará la ventana de datos así como su visualización. 


Línea de mandatos 


La última ventana es la línea de mandatos propiamente dicha, donde se ejecutan los 
mandatos de SoftICE. Además, incorpora el registro histórico de todos los mandatos 
anteriores y otra información complementaria del producto. Utilícense las siguientes teclas 
para desplazarse entre las diferentes ventanas (entre paréntesis el equivalente en inglés): 


RePág (PageUp) — muestra la página anterior del histórico 

AvPág (PageDn) — muestra la página siguiente del histórico 

Flecha de mayúsculas-flecha de desplazamiento hacia arriba (Shift-arrow up) 
—una línea hacia arriba en el histórico 

Flecha de mayúsculas-flecha de desplazamiento hacia abajo (Shift-arrow 
down) — una línea hacia abajo en el histórico 

Alt-flecha hacia arriba (Alt-arrow up) — una línea hacia arriba en la ventana de 
datos 

Alt-flecha hacia abajo (Alt-arrow down) — una línea hacia abajo en la ventana 
de datos 

Alt-RePág (Alt-PageUp) — una página hacia arriba en la ventana de datos 

Alt-AvPág (Alt-PageDn) — una página hacia abajo en la ventana de datos 

Ctrl-RePág (Ctrl-PageUp) — una página hacia arriba en la ventana de código 

Ctrl-AvPág (Ctrl-PageDn) — una página hacia abajo en la ventana de código 

Ctrl-flecha hacia arriba (Ctrl-arrow up) — una línea hacia arriba en la ventana 
de código 

Ctrl-flecha hacia abajo (Ctrl-arrow down) — una línea hacia abajo en la 
ventana de código 


| 
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Puntos de corte 
En la última parte de este capítulo se describirá lo que son los puntos de corte, su 
uso, las distintas formas de almacenarlos en el código de programa y de detectarlos. Ahora 
se indicará cómo definirlos y controlarlos. 
En SoftICE, se pueden utilizar los siguientes puntos de corte: 
e Punto de corte en una ejecución 
e Punto de corte en el acceso a memoria 
e Punto de corte en un rango de accesos a memoria 
e Punto de corte en el acceso a un puerto de entrada/salida 


+ Punto de corte en una interrupción 


e Punto de corte en un mensaje Windows 


Punto de corte en una ejecución 


Representa el tipo más común de punto de corte, Como su nombre indica, se 
practica el punto de corte en la ejecución de una instrucción dada. Si se han llegado a 
cargar las funciones exportadas de las DLLs correspondientes en SoÑtICE, también se 
podrán definir puntos de corte según los nombres de las funciones API, SoftICE detectará 
de igual modo la dirección definida por el punto de corte. Siguiendo el mismo 
procedimiento se podrán establecer puntos de corte comunes a las direcciones de 
instrucciones individuales. 


Sintaxis: *bpx dirección | nombre de función' 
Ejemplo: 


e 'bpx MessageBoxA' — establece el punto de corte en la función APT 
MessageBoxA 


e  'bpx 00401000 — establece el punto de corte en la instrucción de la 
dirección 00401000. 
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Punto de corte en el acceso a memoria 

Aquí el punto de corte se establece en una posición de memoria. Se asemeja mucho 
al anterior. Ahora bien, no sólo se puede definir en la ejecución, sino también en otras 
operaciones y en una cierta dirección de memoria. Los parámetros de acceso indicarán si 


se realiza en modo de escritura o de lectura. 


Sintaxis: “bpm dirección | nombre_de función 
parámetro _de acceso" 


A continuación se indican los parámetros de acceso: 
e  r—lectura 
e  w-escritura 
e  rw-— lectura y escritura 


+ x-— ejecución, el punto de corte se comportará igual que con el mandato 


“bpx" 
Ejemplo: 
+. “bpm 00401000 x' — define el punto de corte en modo lectura en la 


dirección 00401000 


+. 'bpm MessageBoxA x' — define el punto de corte en la ejecución de 
la función API MessageBoxA 


Con frecuencia los puntos de corte de este tipo se utilizan para supervisar una cierta 
posición de memoria y las operaciones que ahí se realizan, por ejemplo, la introducción de 
una contraseña, un número de serie, etc. Se suele combinar con el mandato *s” para buscar 
en cadenas de caracteres, lo que permitirá calcular la posición exacta del algoritmo de 
protección. 


Punto de corte en un rango de accesos a memoria 


Este tipo de punto de corte es prácticamente idéntico al anterior. La principal 
diferencia estriba en que los puntos de corte en un rango de accesos a memoria no sólo 
pueden definirse para una sola dirección, sino para un área de memoria. Estos puntos de 
corte no pueden emplearse en WindowsNT/2000/XP. 


Sintaxis: “bpr dirección inicial dirección final 
parámetro de acceso' 
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Los parámetros de acceso son los mismos que los de la sección anterior: 

e  r-— lectura 

e  w-escritura 

e rw — lectura y escritura 

Ejemplo: 

e 'bpr 00401000 00402000 rw” -— define el punto de corte en 
modo lectura y escritura en el área de memoria comprendido entre la 
dirección 00401000 y 00402000. 

El mandato también se puede utilizar con nombres de funciones: 

e “'bpr MessageBoxA MessageBoxA+10 r' -— define el punto de 

corte en la lectura de los primeros diez bytes de la función API 


MessageBoxA. 


Si bien este tipo de punto de corte se utiliza con mucha frecuencia allí donde los 


otros dos anteriores no son de gran provecho, parece muy difícil encontrar algún caso en el 


que no se pueda realizar la detección. Aunque suele resultar sencillísimo, en este libro se 


incluirá una introducción sobre el asunto. 


Punto de corte en el acceso a un puerto de entrada/salida 


Este punto de corte se realiza en un puerto concreto del ordenador. 
Sintaxis: bpio puerto parámetro _de_acceso' 
Los parámetros de acceso podrán tener los siguientes valores: 

e  r—lectura 

e  w-escritura 

e rw - lectura y escritura 


Este tipo de puntos de corte resulta idóneo para, por ejemplo, anular la protección 


por hardware, normalmente conectada al puerto paralelo. 
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Ejemplo: 
+. 'bpio 378 r' — define el punto de corte en lectura del puerto paralelo 
Punto de corte en una interrupción 
Su nombre resulta autoexplicativo. 
Sintaxis: *bpint número _de interrupción" 
Ejemplo: 
o '“bpint 3'-— define el punto de corte en el interruptor número 3, 
Punto de corte en un mensaje Windows 
Un punto de corte en un mensaje de Windows examina la cola de mensajes en 
busca del recurso definido por el manejador. Este tipo de puntos de corte se emplea 
frecuentemente con programas de los que no se sabe cómo generan ventanas. Para 
solucionarlo, ha de definirse al manejador la ventana (por ejemplo, mediante el mandato 
“hwnd”) y establecer puntos de corte en un mensaje concreto de Windows. Normalmente 
se utiliza el mensaje WM_DESTROY para suprimir la ventana de la pantalla. Al cerrar 


esta ventana, SoftICE mostrará un cuadro de diálogo. 


Véase la parte de referencia de este libro si se desea consultar una lista de los 
mensajes Windows más conocidos. 


Sintaxis: 'bmsg manejador mensaje_de_Windows' 
Ejemplo: 


+ 'bmsg 12345 WM_DESTROY' — define el punto de corte en el recurso 
cuyo manejador sea 12345h y el mensaje WM_DESTROY. 


GESTIÓN DE LOS PUNTOS DE CORTE 

Para facilitar su uso, en SoftICE todos los puntos de corte están numerados. 
Listado de los puntos de corte 

Sintaxis: *b1' 


Esta función enumera todos los puntos de corte (activos y no activos) con sus 
parámetros. 


76 CRACKING SIN SECRETOS CRA-MA 


Ejemplo: 
+ “bl” 


Mostrará algo parecido a lo siguiente: 


00) BPX HXXXX:00012345 
01) BPMB HXXXX:00006789 RW DR3 


Supresión de los puntos de corte 


Sintaxis: 'bc punto de corte _1, punto de corte 2...' 


Esta función elimina los puntos de corte señalados. 
Ejemplo: 
e  'bc 0*-—elimina el punto de corte número O 
e  'bc 1,4' —elimina los puntos de corte números 1 y 4 
e be *' —elimina todos los puntos de corte 
Activación y desactivación de los puntos de corte 


Sintaxis: 'bd punto de corte 1, punto de corte 2...' — 
desactivación 


'be punto de corte 1, punto de corte 2...'-—activación 


Ejemplo: 
e “bd 1,2,3,5' - desactiva los puntos de corte y números 1, 2, 3 y 5 
e  'be 1'-activa el punto de corte número l 
e “bd **'-— desactiva todos los puntos de corte 


e “be *'-—activa todos los puntos de corte, 
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GESTIÓN ESTRUCTURADA DE EXCEPCIONES (SEH) 


Descripción y uso de la gestión estructurada de excepciones 


Entre las distintas posibilidades que ofrecen en la actualidad los sistemas operativos 
Win32, SEH (“Structured Exception Handling”, en inglés), se encuentra entre las más 
utilizadas, pero curiosamente, también es una de las menos documentadas. No basta con la 
buena documentación de mandatos como *_try', '_finally! o 'except'. Tan 
sólo constituyen servicios de librería de un lenguaje de programación. No existe la 
documentación debida de la SEH real incluida directamente en el sistema operativo, 
Escapa al conocimiento del autor la razón de la carencia de una función tan relevante, 
especialmente en lo que concierne a sistemas operativos tan “estables” como Windows. 


El lector se preguntará qué tipo de comprobaciones y gestión de excepciones están 
relacionadas con el pirateo informático. Quedará sorprendido de su alto número. 
Resultan imprescindibles para la inmensa mayoría de los algoritmos antidepuradores 
de hoy en día (y también de otro tipo). Con frecuencia estos algoritmos se basan en la 
invocación de funciones que persistentemente intentar acceder a recursos accesibles 
sólo en ciertas circunstancias —normalmente cuando se detecta un problema de 
seguridad, por ejemplo, un depurador activo etc.— Por otro lado, cuando todo 
funciona normalmente, el proceso suele finalizar lanzando una excepción, que debe 
gestionarse. Aquí es donde SEH juega su papel. Otra propiedad de SEH es la que 
permite saltar de un anillo a otro (lo que se tratará posteriormente). En general, hace 
mucho más que comprobar excepciones. Los ejemplos resultarán más ilustrativos. 


SEH en desarrollo 


La estructura completa de la SEH comprende varias partes. El primer paso consiste 
en “instalar” nuestro propio código de comprobación y gestión de excepciones —el 
denominado manejador—, y guardar la dirección del anterior para recuperarlo 
posteriormente. Finalmente concluiremos el código cuyas excepciones vayan a 
comprobarse por el manejador, siguiendo una secuencia de cierre específica que 
recuperará el manejador SEH original. El lector podrá comprobar en el código siguiente 
que nuestro nuevo manejador SEH se denomina MyHandler: 


push offset MyHandler // se guarda la dirección de 
//muestro manejador definido 
// en algún lugar del código 

push dword ptr £s: [0] // se guarda la dirección del 
// manejador anterior 

mov fs: [0] esp // instalación del manejador nuevo 


78  CRACKING SIN SECRETOS CRA-MA 


El código siguiente restaurará el manejador SEH original: 


pop dword ptr fs: [0] //recupera el manejador original 
add esp,4 // ajuste de pila (stack) 


El manejador variará según las funciones y excepciones que haya de procesar y 
resolver. 


Cada excepción que ocurra en el programa comportará una gran cantidad de 
información interesante y útil. Esta información se almacena en dos estructuras: 
CONTEXT y EXCEPTION_RECORD. 


Mientras EXCEPTION_RECORD describe la excepción conforme suceda, 
CONTEXT incluye una lista de los datos actuales en los registros del procesador. 


Será el valor devuelto por el manejador el que determine cómo procederá la 
ejecución del código del programa. Son dos los valores destacables: 


EXCEPTION_CONTINUE_EXECUTION =0 


e La excepción quedó identificada, procesada y restaurada; el manejador ordena 
seguir ejecutando el programa. En caso de que no fuera restaurada, 
necesariamente sucederá de nuevo. 


EXCEPTION_CONTINUE_SEARCH = 1 


+ El manejador no procesó la excepción y la entrega al manejador siguiente en la 
pila para su posterior procesamiento. 


Los manejadores aquí utilizados no resolverán ninguna excepción complicada, 
sencillamente saltarán los bloques de datos con código defectuoso en la inmensa 
mayoría de los datos. 


Las instrucciones que más recientemente se hayan procesado antes de que ocurra la 
excepción se almacenarán en el registro EIP, incluido, junto a otros registros, en la 
estructura de CONTEXT. Su tamaño aumentará según lo que la longitud exceda de lo 
previsto (esto es, la longitud de las instrucciones defectuosas), de manera que las 
instrucciones defectuosas se saltan y con ellas, la excepción. Si el manejador no resolviera 
la excepción de este modo y el valor obtenido fuera 0 
(EXCEPTION_CONTINUE_EXECUTION), lo que indicaría que el programa continúa su 
ejecución, la excepción volvería a suceder. 
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Algoritmos comunes 
ALGORITMOS BASADOS EN LA FUNCIÓN API CREATEFILEA 


Seguramente, la manera más común de detectar SoftICE consista en procurar 
acceder a sus “drivers” (VxD en Windows 9X, SYS en WindowsNT) y librerías de todo 
tipo que empleen la función API CreateFileA (o su gemela para WindowsNT en Unicode 
CreateFileW). 


Estos algoritmos se han hecho muy populares dada su increíble facilidad de uso 
inclusive en los lenguajes de programación de más alto nivel. Desgraciadamente, la 
función API CreateFileA se ha extendido tanto habida cuenta de su frecuente uso que ya 
no supone ningún obstáculo, ni para los principiantes, superar este tipo de detección. 
Razón por la que su utilidad queda prácticamente relegada si se desea disponer de un buen 
algoritmo de protección. Resulta sorprendente que los sistemas de protección utilizados 
hoy en día sigan aplicando este método histórico de detección. 


Startup failure 


dl U h This Program does not run or machines with active system debugger, 


Figura 2-3. Muchas protecciones evitan los depuradores 


Estos métodos para detectar SoftICE se han hecho tan populares entre los 
crackers que la mayoría de ellos renombran todos los drivers y librerías del SoftICE 
que estén utilizando para no molestarse en buscar y anular estos métodos de protección 
(por muy fácil que resulte). 


En este libro no se examinarán todos estos métodos para detectar SoftICE; por 
razones históricas se describirá el que probablemente sea el más famoso basado en el 
principio recién descrito. Conocido como MeltICE, detecta SoftICE accediendo a sus 
“drivers” —el “driver” VxD pertinente se denomina SICE en Windows 9x/Me y 
NTICE, el correspondiente “driver” SYS para la versión NT de SoftICE—. Hay otros 
“drivers” de SoftICE que pueden detectarse del mismo modo, por ejemplo, un “driver” 
con nombre SIWDEBUG u otro “driver” gráfico SIWVID. 
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Resulta muy sencillo: 


JERHAARAWINAOWS 9x/Mex**k*xxx/ 

HANDLE File = CreateFile(“AMAX.ÍSICE ”,GENERIC_READ | 
GENERIC WRITE, FILE _SHARE_READ | 
FILE SHARE WRITE,NULL,OPEN_EXISTING, FILE _ATTRIBUTE_NORMAL 
¡¿NULL) ; 


if(File != INVALID HANDLE VALUE) // ¿driver SoftICE 
YA localizado? 
( 


CloseHandle (File); 
MessageBox (“SoftICE detectado” ,NULL,MB_OK); 


) 


else 
MessageBox ("SoftICE no detectado” ,NULL,MB_0K); 


[ooo windows NT/2000/XP*******/ 

HANDLE File = CreateFile(“AMAN.AWNTICE ”,GENERIC_READ | 
GENERIC_ WRITE, FILE _SHARE_READ | 
FILE SHARE WRITE,NULL,OPEN_EXISTING, FILE _ATTRIBUTE_NORMAL, 
NULL) ; 

if(File != INVALID _HANDLE_VALUE) // ¿driver SoftICE 

1! localizado? 


CloseHandle (File); 
MessageBox ("SoftICE detectado” ,NULL,MB_OK); 


) 


else 
MessageBox (“SoftICE no detectado” ,NULL,MB_0K) ; 


LA INTERFAZ BOUNDSCHECKER Y EL USO DE INIT3 


El siguiente es uno de los procedimientos habituales de detectar SoftICE. Emplea su 
interfaz, que permite control parcial, incluso desde otros programas. La interfaz más 
conocida de este tipo se denomina BCHK (BoundsChecker); otra también bien conocida 
es la llamada FGJM. Como en el caso anterior, se persigue acceder a la interfaz de 
SoftICE. Si se negara el acceso, SoftICE no estaría activo. De lo contraro, SoftICE sí 
estaría activo (o bien se habría producido algún error inesperado —pudiéndose comprobar 
entonces el valor de retorno para asegurarse—), y así quedarían accesibles con otros fines 
las funciones propias de BoundsChecker. A la interfaz BoundsChecker la invoca la 
interrupción INIT3, el número de función solicitada por el registro EAX y otros valores 
“mágicos” de los registros pertinentes. Por esta razón, la instrucción INT3 no resulta 
procesada por el sistema sino por SoftICE. 
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SoftICE sólo procesará la invocación a INIT3 si está activo. En caso contrario, el 
sistema procesará INT3, con lo que se generará una excepción STATUS_BREAKPOINT 
que deberá ser reparada por nuestro servicio SEH. Éste es el modo de saber si SoftICE está 
o no activo. Si a INT3 no le preceden valores apropiados en los registros, la invocación 
siempre será procesada por el sistema (a no ser que el mandato i3here de SoftICE esté 
activo —algo que se estudiará más adelante). Esta propiedad de SEH constituye también 
un método para generar excepciones, aunque, como se indicará más adelante en la sección 
sobre puntos de corte, esta llamada a la interrupción resulta muy fácil de detectar. Razón 
por la que ha de considerarse simplemente como un ejemplo que otra excepción sustituya 
(y hay muchas donde elegir). 


SEH también puede controlar la comprobación de excepciones. Puede aplicarse 
la popular función API SetUnhandledExceptionFilter a expensas de 
degradar considerablemente la seguridad de los mecanismos de protección. Ya se ha 
comentado el uso innecesario de las funciones API en los mecanismos de protección y 
se volverá a insistir en el asunto en este capítulo también, en la sección dedicada a 
puntos de corte, 


Para comprobar si SoftICE está activo, guardaremos el valor mágico BCHK = 
BoundsChecker en el registro EBP, y el valor 4 el registro EAX. El código resultante 
será parecido al siguiente: 


_ asm 
( 
push offset MyHandler // guardando dirección 
de nuestro 
manejador 
push dword ptr fs: [0] // guardando dirección 
del manejador 
anterior 
mov fs: [0] esp // instalación 
push ebp // valor EBP guardado 
mov ebp,4243484Bh // EBP =(ASCII)BCHK = 
BoundsChecker 
mov eax,4 // EAX contiene la 
función 
solicitada 
INT 3 // Llamada a 


BoundsChecker - si 
SoftICE no está 
activo, el sistema 
procesa la llamada, 
con lo que 
MyHandler procesará 
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nop 


pop ebp 
pop dword ptr fs: [0] 


add esp,4 
cmp eax,4 


jz No _SoftICE 


jmp SoftICE 


MyHandler: 


mov edx, [esp+0Ch] 
mov ecx, [esp+4] 
mov eax,80000003h 


mov ecx, [ecx] 


sub eax,ecx 


je Ok 


la excepción | 
resultante 

// NOP por 
compatibilidad con 
sistemas Win32 - 
cuando INT3 causa la 
excepción, EIP 
(NT/2000/XP) señala 
a INT 3, pero 
EIP(9x/Me), a NOP 

// recuperación de EBP 

// recuperación del 
manejador anterior 

// ajuste de pila 

// si SoftICE procesa 
INT3, EAX cambiará 
de valor 

// en caso contrario 
el sistema procesará 
INT3 o habrá 
sucedido una 
excepción inesperada 


// para facilitar el 
acceso se leen las 
estructuras CONTEXT 
y EXCEPTION RECORD 
en e.g. ECX y EDX 

// CONTEXT 

// EXCEPTION_RECORD 

// EAX = valor de la 
excepción provocada 
por la instrucción 
INT3- 
STATUS_BREAKPOINT 
(80000003h) 

// ECX = número de 
excepciones 
generadas 

// comparación de los 
valores de EAX y ECX 

// seguir si los 
valores de las 
excepciones son 
idénticos 


GRA-MA CAPÍTULO 2: PROTECCIÓN CONTRA LOS PROGRAMAS DE DEPURACIÓN _ 83 


sub eax,eax // otra excepción, que 
no se procesará por 
manejador 

inc eax // ExceptionContinueSearch 

jmp End 

Ok: 

add dword ptr [edx+0B8h],1 // el valor ElIP se 
amplía 1 byte,1.e., 
la longitud de la 
instrucción INT3 
(CcCch) 

// así se saltará la 
instrucción y se 
evitará la excepción 

sub eax,eax // ExceptionContinueExecution 
End: 

ret 
No_SOoftICE: 

MessageBox ("SoftICE no detectado” ,NULL,MB_O0K) ; 

return; 
SoftICE: 


MessageBox (” Soft ICE detectado” ,NULL,MB_O0K) ; 


Si se optara por una aplicación más fácil haciendo uso de la función API 
SetUnhandledExceptionFilter, el código podría ser el siguiente: 


long __stdcall MyHandler (_EXCEPTION_POINTERS 
*ExceptionInfo) 
( 


an (ExceptionInfo->ExceptionRecord->ExceptionCode == 
0x80000003) 


( 


ExceptionInfo->ContextRecord->Eip +=1; 
// excepción 
return EXCEPTION CONTINUE _EXECUTION; 


) 


return EXCEPTION _CONTINUE_SEARCH; 
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( 
LPTOP_LEVEL_EXCEPTION_FILTER Previous = 
SetUnhandledExceptionFilter (MyHandler) ; 
_ asm 
( 
push ebp // se guarda el valor 
EBP 
mov ebp, 4243484Bh // EBP =(ASCIT)BCHK = 
BoundsChecker 
mov eax, 4 // EAX contiene la 
función solicitada 
INT 3 // llamada a 
BoundsChecker - 
MyHandler procesará 
una excepción si 
SoftICE no estuviera 
activo 
nop 
pop ebp // se recupera EBP 
cmp eax,4 
Jz No_SoftICE 
) 
MessageBox ("SoftICE detectado” NULL, MB_OK) ; 
SetUnhandledExceptionFilter (Previous); 
return; 
No_SOftICE: 
MessageBox (“"SoftICE no detectado” ,NULL,MB_OK); 
SetUnhandledExceptionFilter (Previous); 
) 


Acúdase a la sección de referencia del libro si se desearan conocer otras funciones 
de la interfaz BoundsChecker y su uso. Si aún resultase insuficiente, en el manual 
denominado “Ralf Brown's Interrupt List” incluido en el CD adjunto, se podrá encontrar 
una lista de todas las interrupciones para todo tipo de programas comunes o 
insospechados. 


La manera de detectar el depurador TRW resulta prácticamente idéntica. La 
única diferencia radica en que no es necesario guardar ningún valor mágico en los 
registros antes de la invocación a INT3. Si TRW no estuviera activo, se generaría una 
excepción. 
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EMPLEO DE INT1 


Si se sustituye INTI por INT3, no se precisa guardar ningún otro valor en los 
registros, al igual que con la detección de TRW. Desgraciadamente, este método sólo 
funciona con los sistemas operativos NT, 2000 y XP, lo que a su vez exige detectar el 
sistema operativo: 


mov eax,cs 

test al,100b 

jne Win9x // salir si el sistema 
operativo fuera 
Windows 9x/Me 


o: 

push fs: [30h] 

pop eax 

test eax, eax 

js Win9x // salir si el sistema 
operativo fuera 
Windows 9x/Me 

o 

mov ax,ds 

test al,4 

jne Win9x // salir si el sistema 


operativo fuera 
Windows 9x/Me 


Cuando se utiliza INTI, el manejador debe ser un poco más sofisticado, puesto que 
esta interrupción provoca una excepción incluso aunque SoftICE se encuentre activo. Si así 
fuese, INT1 causará la excepción STATUS _SINGLE_STEP = 80000004h; y en 
caso contrario, la excepción STATUS_ACCESS VIOLATION = C0000005h. Ha de 
ponerse también cuidado con el valor del registro EP. Cuando SoftICE esté activo, 
EIP señalará la instrucción siguiente a INTI, con lo que no se tendrán que ajustar nada 
manualmente. Si, por el contrario, SoftICE no estuviera activo, EIP señalará la 
instrucción que provocó la excepción —esto es, INTI—. Ésta es la causa de que el 
registro EIP deba ampliarse en 2 bytes (la longitud de la instrucción INT1 - CDO1h). 
El código resultante se asemejará al siguiente: 
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asm 


( 


mov 


mov ax, ds 
test al,4 


jne Win9x 


xor eax,eax 
push offset MyHandler 


push dword ptr fs: [eax] 


fs: leax] esp 
INT 1 
pop dword ptr fs: [0] 


add esp,4 

cmp eax,4 

jz No_SoftICE 
jmp SoftICE 


MyHandler: 


mov edx, [esp+0Ch] 
mov ecx, lesp+4] 
mov eax,80000004h 


mov ecx, [ecx] 


sub eax,ecx 


je Ok 


sub ecx,0C0000005h 


// identificación del 


sistema operativo 


// salir si el sistema 


operativo fuera 
Windows 9x/Me 


// EAX = 0 
// guardando la 


dirección de nuestro 
manejador 


// guardando la 


dirección del 
manejador anterior 


// instalación 


// recuperación del 


manejador anterior 


// ajuste de pila 
// SOftICE detectado? 


// CONTEXT 
Ef EXCEPTION_RECORD 
// EAX = valor de la 


excepción 
STATUS_SINGLE_STEP 
causado por INT1 
cuando SoftICE está 
activo 


// ECX = valor de la 


excepción recién 
generada 


// comparación de los 


valores de EAX y ECX 


// si los valores de 


las excepciones son 
idénticos, SoftICE 
está activo 
// si SoftICE no está 
activo, INT 1 
provocada la 
excepción 
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STATUS_ACCESS_VIOL 
ATION (C0000005h) 


je No_NTIce // ¿ es la excepción 
STATUS_ACCESS VIOLATION? 
sub eax,eax // se género un error 


y no será procesado 
por este manejador 


inc eax // ExceptionContinueSearch 
jmp End 

No_NTIce: 
add dword ptr [edx+0B8h],2 // se restaura la 


excepción saltando 
la instrucción 
incorrecta 

mov [edx+0B0h],4 // 4 guardado en EAX - 
SoftICE no detectado 


Ok: 
sub eax,eax // ExceptionContinueExecution 
End: 
ret 
) 
Win9x: 
MessageBox ("Este método sólo funciona con Windows 
NT/2000/XP” ,NULL,MB_OK); 
return; 
No_SOftICE: 
MessageBox (“SoftICE no detectado” ,NULL,MB_OK); 
return; 
SoftICE: 


MessageBox ("SoftICE detectado” ,NULL,MB_0K); 


Error 


Figura 2-4. Armadillo resulta muy sobrio cuando detecta un depurador 
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EMPLEO DE INT 68H 


Por el contrario, la detección de un depurador empleando la interrupción INT 68h, 
para lo que no se requiere SEH, funciona sólo con Windows 9x/Me. El sistema siempre 
procesa INT 68h y no suceden excepciones. 


asm 


( 


mov ax, ds 


test al,4 // identificación del 
sistema operativo 
je Not_Win9x // fin si el sistema 


operativo fuera 
Windows 9x/Me 


mov ah, 43h // AH = número de 
servicio 

INT 68h 

cmp ax,0F386h // si el valor 


devuelto fuera otro 
número “mágico” 
F386h, SoftICE 
estaría activo 


jz SoftICE 


MessageBox (“"SoftICE no detectado” ,NULL,MB_OK); 
return; 


SoftICE: 
MessageBox (“SoftICE detectado” ,NULL,MB_OK); 


return; 


Not_Win9x: 
MessageBox (“Este método sólo funciona con Windows 


9x/Me” ,NULL,MB_0K) ; 


BÚSQUEDA EN EL REGISTRO DE WINDOWS 


Un método muy simple y eficaz para detectar la instalación de SoftICE en un 
ordenador dado consiste en buscar por el registro de Windows. Se incluye aquí con ánimo 
de ser exhaustivos puesto que este método, al igual que sucedía con el basado en el uso de 
CreateFileA, no supone ningún obstáculo para un cracker experimentado. La mayoría 
de ellos han renombrado o modificado de alguna manera todas las definiciones hechas en 
el registro por SoftICE para impedir el funcionamiento de este método de detección. Por 
otro lado, este método sólo permitirá detectar la instalación de SoftICE en un ordenador 
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concreto, y no si está activo. Por eso debiera considerarse cl resultado de esta 
comprobación como una señal de advertencia, y no la clave de la protección. Resulta lícito 
solicitar al usuario que inactive el depurador mientras se utilice un programa, pero no que 
lo desinstale. El mismo problema afecta a los mismos métodos de detección con otros 
programas (desensambladores, editores hexadecimales, etc.) razón por la que no se ha 
incluido en este libro. 


HKEY Key; 
BYTE VerDataBuffer[200],InstDataBuffer [200]; 
DWORD VerSize = 5,InstSize = 128; 


if (RegOpenKeyEx (HKEY_LOCAL_ MACHINE, 
"SoftwarelINuMegalYYSOftICEAX” NULL, KEY_ READ, $Key) == 
ERROR_SUCCESS) // ¿se detectó 

// la clave añadida por SoftICE? 


( 
RegQueryValueEx (Key, "Current 
Version” ,NULL,NULL,VerDataBuffer,$VerSize); 

// SoftICE version 
RegQueryValueEx (Key, "InstallDir” NULL, NULL, 
InstDataBuffer, £InstSize); // directorio de 

// instalación de SoftICE 
MessageBox ( (const char*) InstDataBuffer, (const 
char*)VerDataBuffer,MB_0K); 
) 
else 


MessageBox ("SoftICE no detectado” ,NULL,MB_0K) ; 


Figura 2-5. SoftICE detectado 


BÚSQUEDA EN AUTOEXEC.BAT 


En los sistemas operativos Windows 9x/ME, el fichero autoexec.bat arranca 
SoftICE. Lo que facilita enormemente su detección mediante la búsqueda en dicho fichero 
de la referencia a winice.exe. En este caso se ha empleado MFC (Microsoft Foundation 
Class) para trabajar con cadenas de caracteres: 
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CFile File; 

char SIString[] = “winice.exe”; 
CString String; 

BOOL SoftICE = FALSE; 


if (File.Open(“c:llautoexec.bat”,CFile: :modeRead) € 
File.GetLength() != 0) 
( 
BYTE *pMem = new BYTE [File.GetLength()+1]; 
// asignación de memoria 
File.Read (pMem, File.GetLength () +1); // carga del 
// fichero en memoria 


String = pMem; 

String.MakeLower () ; // conversión de todas 
las letras a 
minúscula 


for (int i = 0;i < String.GetLength()- 
strlen (SIString) ;1++) 
( // búsqueda gradual de 
la secuencia por 
todo el fichero 


if (String.Mid(i,strlen(SIString)) == SIString) 
// cadera detectada 
( // ¿nwinice.exe “? 
SoftICE = TRUE; 
break; 
) 


delete []pMem; 


) 
if (SoftICE) 

MessageBox (“SoftICE detectado” ,NULL,MB_0K); 
else 

MessageBox (“SoftICE no detectado” ,NULL,MB_OK); 


Con mucha frecuencia se encuentran algoritmos que hacen uso de los vectores 
de interrupción. Generalmente se considera que estos algoritmos son los mejores 
puesto que no utilizan ninguna función API y, por tanto, no resultan fácilmente 
detectables ni identificables. Sin embargo, la realidad es bien distinta. No constituye 
ningún problema identificar cualquier intento de utilizar IDT (véase “Privilegios de 
anillo” o el capítulo 4 - FrogsICE) por parte de un programa, encontrar su protección y 
anularla. 
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PUNTOS DE CORTE 


La definición de puntos de corte constituye una parte crucial de cada depurador. No 
es más que un juego de mandatos con sus parámetros que ejecuta el depurador para 
interrumpir la ejecución de un programa y permitir su depuración según las circunstancias. 


En la inmensa mayoría de los casos, los puntos de corte se definen en llamadas a 
funciones API por estar bien documentadas y, sobre todo, por el hecho de que se utilizan 
con mucha frecuencia por programadores y crackers. Las funciones API, por tanto, son el 
mejor punto de entrada a los programas. 


Ya se ha señalado en el capítulo 1 (donde se puede encontrar una lista 
exhaustiva de las funciones APT mejor conocidas) el uso de las funciones API en los 
algoritmos de protección. Después de haber presentado en las anteriores secciones los 
distintos tipos de puntos de corte que se pueden definir con SoftICE, apenas resulta 
necesario señalar lo fácil, en mayor o menor medida, que resulta para un cracker 
identificar dónde se ubica el algoritmo de protección en un programa. Éste será el sitio 
idóneo para que los puntos de corte apunten a funciones del propio programa y vayan 
penetrando hasta el corazón de la protección y del programa. 


Por lo tanto, téngase en mente que cualquier uso de una función API en un 
mecanismo de protección reduce su seguridad global. Lo primero que un cracker 
intentará emplear al buscar la ubicación del algoritmo de protección serán las 
funciones API, cuya invocación resulta fácilmente identificable utilizando puntos de 
corte en un depurador. 


El lector podrá apreciar que con los depuradores, los puntos de corte 
constituyen el peligro número uno; por eso se debe prevenir su uso, 


Ya se han examinado los distintos tipos de puntos de corte en la sección sobre el 
uso del SoftICE. Se puede dividir según se dirijan al software o al hardware. Los 
primeros se “guardan” directamente en el software, mientras que los de hardware se 
guardan directamente en la CPU, en los denominados registros de depuración. Los 
puntos de corte para software se definen mediante mandatos bpx, bpr y bpint, 
mientras que los de hardware se definen con los mandatos bpm y bpio. 


Puntos de corte para software 


PUNTOS DE CORTE EN UNA INTERRUPCIÓN (BPINT) 


Conforme se viene indicando, muchos algoritmos de protección se centran 
principalmente en evitar el uso de SoftICE invocando diversos tipos de interrupciones. Lo 
que pudiera llevar a pensar que los puntos de corte sobre interrupciones suponen una 
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solución ideal. No ocurre así realmente. No debe olvidarse que un punto de corte se define 
sobre una interrupción del sistema, no sobre una interrupción de SoftICE. El punto de 
corte sólo se podrá utilizar cuando sea el sistema el que realice la interrupción 
independientemente de que SoftICE esté activo. (¿Cómo se podría establecer el punto de 
corte si no estuviese activo?). Así sucede con INT 68h; en caso contrario, los puntos de 
corte de esta índole no resultan útiles. Por eso no deben utilizarse interrupciones para, por 
ejemplo, generar excepciones con SEH si se desea mantener la seguridad. 


Resulta pertinente mencionar a este respecto dos mandatos de SoftICE muy 
parecidos al uso de puntos de corte en interrupción, concretamente ilhere ON/OFF e 
i3here ON/OFF. Los resultados obtenidos al activar estos mandatos son casi idénticos a 
los puntos de corte bpint sobre las interrupciones INT1 e INT3. La única diferencia estriba 
en que SoftICE procesa las llamadas a la interrupción, con lo que no sucede ninguna 
excepción. Resultan utilísimos cuando se desea depurar cierto lugar de un programa sin 
necesidad de buscarlo durante mucho tiempo. Basta con realizar la invocación en una de 
las interrupciones (normalmente a INT3) en el lugar indicado y definir el mandato 
oportuno. 


PUNTOS DE CORTE EN UNA EJECUCIÓN (BPX) 


SoftiCE (y otros depuradores) sobrescriben las secciones del programa donde se 
definen puntos de corte en ejecución con el valor INT3 (una interrupción bastante obvia), 
esto es, CCh. Así, obtiene la información de que se va a interrumpir la ejecución del 
programa. Cuando se ejecute el código del programa, todas las secciones que se hayan 
modificado de esta manera se volverán a escribir con el valor original y así evitaremos un 
error en el programa, De este modo, sólo será preciso comprobar los bytes del código 
elegido o del área de memoria, etc., sobrescritos en memoria a CCh, esto es, INT3, para 
encontrar un punto de corte en una ejecución. Se puede alegar, con razón, que el valor 
CCh del código no sólo resulta válido para INT3, sino que puede formar parte de cualquier 
otra instrucción. Por eso, este método debiera utilizarse preferentemente para comprobar 
código del que se sabe con certeza que no contiene el valor CCh en las áreas de memoria 
que se van a examinar. Este método se torna ineficaz para comprobar grandes áreas de 
código desconocido —resulta preferible utilizar comprobaciones de integridad de los datos 
(“checksums”, en inglés) — (véase el capítulo 6). 


Este método resulta idóneo cuando se desea realizar una comprobación rápida y 
sencilla de la presencia de puntos de corte bpx en funciones comunes o importantes en el 
código. Es exactamente todo lo que se precisa para comprobar las funciones API. 


En el siguiente ejemplo se comprueban los cinco primeros bytes de la función API 
DialogBoxParamA de un punto de corte bpx: 
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EHMODULE Handle = GetModuleHandle (“user32"); // imageBase 
// user32 


FARPROC Address = 
GetProcAddress (Handle, "DialogBoxParamA”); 
// dirección de la 

función 
DialogBoxParamA 

byte Function[5]; 

memcpy (£Function, Address, sizeof Function); // función = 
los 5 primeros bytes 
de la función 


for (int i = 0;i < 5;1++) 


( 


if (Function [i] == 0xCC) // ¿ detectado punto 
de corte bpx? 
( 


MessageBox ("Punto de corte BPX 
detectado” NULL, MB_O0K); 
return; 

) 


MessageBox ("Punto de corte BPX no detectado” ,NULL,MB_OK) ; 


No sólo se puede obtener la dirección de la función mediante la función API 
GetProcáddress. Se puede obtener de igual manera empleando el formato PE (y las 
funciones importadas). En la sección dedicada al formato PE del capítulo 7 se abundará 
más en esta cuestión. 


PUNTOS DE CORTE EN UN ÁREA DE MEMORIA (BPR) 


Desde que los puntos de corte bpx y bpm dejaron de ser una novedad hace tiempo, 
los crackers se han dado prisa en aprender otras alternativas: los puntos de corte bpr, 
Resulta bastante sorprendente que aún no los haya detectado ningún sistema de protección 
a pesar de que su realización sea mucho más simple que con los puntos de corte bpm. 


Para poder detectar los puntos de corte bpr, es necesario saber primero, cómo se 
definen con SoftICE. 


Al no definirse sobre una única dirección los puntos de corte de este tipo, sino sobre 
un área de memoria dada, el procedimiento difiere del descrito anteriormente. El método 
utilizado por SoftICE es mucho más sofisticado. Se basa en la modificación de los 
derechos de acceso a aquellas páginas de memoria que incluyen áreas en las que se han 
definido puntos de corte. Los privilegios de acceso se modifican a PAGE_NOACCESS, 
con lo que cualquier acceso a las páginas señaladas de memoria (en lectura, escritura, 
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ejecución) causará una excepción. SoftICE la detectará y la corregirá. A continuación 
calculará qué tipo de acceso se realizó y lo comparará con el que se indicó en el punto de 
corte para el área de memoria definida. Si todas estas comprobaciones resultan idénticas, el 
programa se detendrá, el punto de corte habrá cumplido su cometido. 


No resulta nada complicado definir los puntos de corte de este algoritmo de 
detección. Se basa sencillamente en la comprobación de los derechos de acceso de un área 
de memoria específica. Si el derecho de acceso se define como PAGE_NOACCESS, el 
punto de corte bpr quedará establecido en el área de memoria indicada. 


A continuación se muestra un ejemplo de protección mediante puntos de corte bpr: 


MEMORY BASIC INFORMATION Mbi; 
DWORD Address; 


__asm 
BprTest: 
mov Address, offset BprTest // dirección de 
comienzo de la 
comprobación 


) 


VirtualQuery ((void*) Address, £Mbi,sizeof 
MEMORY _BASIC_INFORMATION) ; 


if (Mbi.Protect == PAGE _NOACCESS) // ¿derechos de acceso 
= PAGE _NOACCESS? 
MessageBox (“Punto de corte BPX detectado”, NULL,MB_OK); 
else 
MessageBox (“Punto de corte BPX no detectado”, 
NULL, MB_0K) ; 


La función VirtualQuery identifica los parámetros de la página de memoria 
donde resida la dirección de comienzo de la comprobación, además aporta información de 
todas las páginas adyacentes en memoria con los mismos parámetros (algo complejo hecho 
fácil). Si se definiese un punto de corte bpr en este área de memoria, el algoritmo lo 
detectaría con seguridad. 


Puntos de corte hardware 


Como ya se comentó anteriormente, los registros de depuración de la CPU se 
encargan de guardar directamente los puntos de corte hardware. Se denominan “hardware” 
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por la ubicación donde se guardan (directamente en la CPU, frente a los puntos de corte 
“software”, que se guardan en el software), y también por ser principalmente el 
procesador, y no sólo la herramienta de depuración (como sucede con los puntos de corte 
software) el encargado de su procesamiento. Al resultar idéntico el almacenamiento de 
todos los tipos de puntos de corte hardware disponibles en SoftICE, también (ambos) se 
podrán detectar del mismo modo. 


Empléese el código siguiente si se desea depurar registros definidos en la estructura 
CONTEXT como dobles palabras Dr0O-Dr3,Dr6 y Dr7: 


typedef struct _CONTEXT ( 
DWORD Dr0; 
DWORD Dr1; 
DWORD Dr2; 
DWORD Dr3; 


DWORD Dr6; 
DWORD Dr”7; 


) CONTEXT; 


Los puntos de corte como tales pueden guardarse en los registros Dr0 a Dr3. Dr7 es 
un registro de mandato del sistema de depuración de la CPU y Dró es un registro de 
estado. 


Si el programa estuviera en ensamblador, pruébese el siguiente acceso para depurar 
los registros: 


mov eax,Drl 


Sucederá una excepción de forma natural puesto que estas instrucciones sólo se 
pueden ejecutar en ciertos anillos privilegiados del procesador (que se describirán 
posteriormente). Si bien es cierto que se puede cambiar de uno a otro para poder ejecutar el 
ejemplo anterior, constituye un procedimiento innecesariamente largo que sólo funciona 
con Windows 9x/Me y que apenas confiere más robustez al programa (por no mencionar 
los puntos débiles que acarrea esta técnica de depuración mediante la detección del 
contenido de los registros). 


Resulta preferible sacar partido al SEH clásico. Ya se mencionó en el capítulo 
correspondiente, que las excepciones quedan asociadas a dos estructuras, 
EXCEPTION_RECORD y CONTEXT, y que la última contiene una lista de los registros de la 
CPU, y no sólo los comunes, como EAX, EBX, etc., también los de depuración (como se 
acaba de describir). 
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Desgraciadamente, nada resulta tan fácil como parece: no basta con provocar una 
excepción y comprobar el contenido del registro de depuración en la estructura CONTEXT 
del manejador —esto es, comprobar que es igual a cero (sin puntos de corte definidos) —. 
Al menos no si se va a utilizar esta técnica con todas las plataformas Win32. Parece que si 
este método se aplica a Windows NT/2000/XP —a diferencia de Windows 9x/Me— el 
contenido de los registros de depuración obtenidos en el manejador SEH quedan 
modificados con valores incorrectos. 


Razón que obliga a elegir un método ligeramente diferente. La aplicación primero 
rellena los registros de depuración con sus propios datos (direcciones) con los que se 
establecerán los puntos de corte hardware. Lo que resulta equivalente de hecho a definir 
los puntos de corte en la propia aplicación (quedará parcialmente contemplado en el 
programa). A continuación comprobará que se hayan procesado todos los puntos de corte 
definidos (esto es, que hayan causado la excepción STATUS BREAKPOINT) y en caso 
contrario, que se hayan sobrescrito por los puntos de corte hardware definidos por el 
depurador. 


Para provocar la excepción que necesita el manejador SEH, se suele emplear la 
típica instrucción INT3, Como ya se indicó anteriormente, una excepción provocada de 
esta manera sólo tiene valor pedagógico. Resulta muy sencillo detectarla, debe sustituirse 
el procedimiento de protección por algún otro método para generar excepciones difícil de 
detectar. Por tanto, no debe hacerse referencia a la función API RaiseException. 


Resulta mucho mejor experimentar insistentemente con los ejemplos de puntos de 
corte hardware: los que saltan de anillo y otros semejantes. Además, no sólo se pueden 
emplear para detectar puntos de corte. Se pueden borrar o sobrescribirlos con ánimo de 
detectar el depurador o para muchas otras operaciones. Los puntos de corte hardware son 
interesantes y algunas veces, incluso enigmáticos en ciertos aspectos que merece la pena 
estudiar, 


DESCRIPCIÓN DE UN PROGRAMA DE EJEMPLO EMPLEADO PARA 
DETECTAR PUNTOS DE CORTE HARDWARE 


El corazón de todo el programa radica en un manejador denominado 
BPMHandler. Primero repara la excepción generada intencionadamente (por la 
instrucción INT3). La estructura rellenada con datos tras la generación de la excepción se 
emplea para definir los puntos de corte para la aplicación. Puesto que los puntos de corte 
causan excepciones en otros programas, el manejador se encargará también de capturarlas. 
Se utilizará un solo registro de los puntos de corte tratados para guardar la información en 
la variable Done. Son cuatro los puntos de corte definidos (registros Dr0, 1, 2 y 3). Si el 
valor de la variable Done fuera también 4, los puntos de corte habrán finalizado con éxito. 
En caso contrario, el depurador estaría activo en memoria y se habrían definido algunos 
puntos de corte hardware. Por último, el manejador restaura la última excepción del 
programa causada por la segunda instrucción INT3, cuya tarea consiste en eliminar el 
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registro de mandato Dr7. Al definir los puntos de corte en la aplicación, el registro de 
mandato Dr7 debe completarse con los valores necesarios. Si se deseara saber por qué el 
registro recoge el valor 155h, acúdase a la descripción de los registros Dró y 7 recogida en 
el CD adjunto. Aunque ya supondría adentrarse en un área más avanzada que no resulta 
imprescindible en este momento. 


Igualmente debe ponerse cuidado en el orden en el que se definen los puntos de 
corte. Puesto que el procesamiento de los registros de depuración se inicia en Dr3 hasta 
llegar a Dr0, el primer punto de corte emparejado con la primera sentencia NOP, debe 
guardarse en el registro Dr3 y el último en el registro Dr0. 


DWORD OurAddress; 
BYTE Done = 0O,DR7Break = 0; 


asm 


[ 
push offset BPMHandler // guardando la 
dirección de nuestro 


manejador 

push dword ptr fs: [0] // guardando la 
dirección del 
manejador anterior 


mov fs: [0] ,esp // instalación 


mov OurAddress, offset Address; // OurAddress = 
dirección de 
arranque para los 
puntos de corte 

INT 3 // primera excepción 
intencionada creada 
por INT3 

// instrucción elegida 

para simplificar la 
construcción del 
manejador (como el 
lector habrá 
observado), no se 
emplee en la 
protección bajo 
ningún concepto 

nop 

nop //---1 primer punto de 


corte 
nop 1/ I 
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nop 


nop 


nop 


nop 


Address: 


nop 
nop 


inc DR7Break 


INT 3 


nop 
pop dword ptr fs: [0] 


add esp, 4 
jmp Jump 


BPMHandler: 


mov edx, [esp+0Ch] 
mov ecx, [esp+4] 
push ebp 


mov ebp, [edx+0B4h] 


mov ebx,OurAddress 
mov [edx+4] ,ebx 
sub ebx,2 

mov [edx+8] ,ebx 


A Y 

//---1 segundo punto 
de corte 

IE E 


/1/ I— ubicaciones 
para puntos de corte 
//---1 tercer punto de 


corte 

AE E 

1/1 1 

1/1 

//---1 cuarto punto de 
corte 


// 


// ampliando el valor 
de la variable 
DR7Break..., vacía 
el registro Dr7 en 
el manejador 


// segunda excepción 
intencionada para 
limpiar el registro 
Dr7 


// recuperación del 
manejador anterior 
// ajuste de pila 


// CONTEXT 

AL EXCEPTION_RECORD 

// guardando el valor 
EBP 

// la lectura del 
valor previo EBP 
antes de introducir 
el manejador 
facilita el uso de 
nuestras variables 


// Dro 


// Dr1 
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sub ebx,2 
mov [edx+0Ch] ,ebx 
sub ebx,2 
mov [edx+10h] ,ebx 


and [edx+14h],0 


mov [edx+18h],155h 


cmp DR7Break, 0 


je MYjump 
and [edx+18h],0 


MYjump: 
mov eax,80000004h 


mov ecx, [ecx] 


sub eax,ecx 


je BreakPoint 


dec eax 


je Ok 


1/ 
// 


// 


11 


// 


// 


// 


// 


id 
PP 


4% 


1/ 


Dr2 


Dr3 - contiene el 
punto de corte del 
primer NOP 
limpiando el 
registro Dr6 
definiendo el valor 
del registro de 
mandato Dr”7 

¿fue causa de la 
segunda excepción de 
la instrucción INT 
3? 


en caso afirmativo 
se limpia el 
registro de mandato 
DXx7 


EAX = valor de la 
excepción 

STATUS SINGLE_STEP, 
causada por el punto 
de corte definido 
ECX = valor de la 
excepción recién 
producida 
comparación de los 
valores EAX y ECX 
si los valores de 
las excepciones 
resultan idénticos, 
aumentamos el número 
de puntos de corte 
para tratarlos 
satisfactoriamente 
¿fue causa de la 
excepción 
STATUS_BREAKPOINT 
(80000003h) la 
instrucción INT 3? 
en caso negativo, 
sucedió otra 
excepción de 
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programa, que no 
tratará este 


manejador 
sub eax,eax 
inc eax // ExceptionContinueSearch 
jmp End 
BreakPoint : 
inc Done // aumentando el 
número de puntos de 
corte tratados 
correctamente 
Ok: 
add dword ptr [edx+0B8h],1 // reparando la 
excepción saltando 
la instrucción 
incorrecta 
sub eax,eax // ExceptionContinueExecution 
End: 
pop ebp // se recupera EBP 
ret 
Jump: 
) 
if (Done == 4) // ¿establecidos todos 
los puntos de corte 
satisfactoriamente? 
MessageBox (“Puntos de corte hardware no detectados”, 
NULL, MB_O0K) ; 
else 


MessageBox ("Puntos de corte hardware detectados”, 
NULL, MB_O0K); 


ORA-MA CAPÍTULO 2: PROTECCIÓN CONTRA LOS PROGRAMAS DE DEPURACIÓN _101 


MÉTODOS AVANZADOS 


Privilegios de los anillos 


Un procesador puede funcionar en cuatro niveles diferentes según el número de 
instrucciones privilegiadas que ejecute. Se denominan: anillo 0 (mayores privilegios), 
anillo 1, anillo 2 y anillo 3 (con menores privilegios sucesivamente). La mayoría de los 
programas se ejecutan en el anillo 3 y, por lo tanto, cuentan con más limitaciones. Como 
ya se habrá dado cuenta el lector por los ejemplos empleados con los puntos de corte 
hardware, resulta imposible escribir en los registros de depuración. Existen programas, sin 
embargo, que sí pueden ejecutarse directamente en el anillo O. Entre ellos los drivers 
lógicos VxD y los drivers de dispositivo SYS en Windows 9x/Me y sólo los de tipo SYS 
en Windows NT/2000/XP (los de tipo VxD no pueden emplearse con Windows 
NT/2000/XP). Hay tres formas, que se sepa, de saltar entre el anillo 3 y el anillo 0 
directamente desde el programa: mediante LDT, IDT y SEH. Y que están prohibidos en 
Windows NT/2000/XP por razones de seguridad, sólo se podrán utilizar con Windows 
9x/Me. De hecho, hay un método más de invocar el código del anillo 0 desde una 
aplicación normal: utilizando la función ordinal de la librería kernel32.dll, 
Kerne132!0RD_0001. (En el capítulo 7 se describirá en qué consiste la función ordinal 
— formato PE—. Por ahora basta con saber que es una función sin nombre.) Como de 
costumbre, la función sólo está disponible en Windows 9x/Me, su invocación exige un 
largo procedimiento, mucho más complicado que el procedimiento habitual para saltar al 
anillo 0, y su capacidad, más reducida, no resulta muy útil. Bien es cierto que detectar este 
método resulta algo más difícil, pero lo es mucho más el basado en SEH, Por eso no se 
describirá en este libro, bastará con constatar su existencia indicando que se aplica 
principalmente en VxDCalls, que se describirá a continuación. En cierto sentido es triste 
que una técnica tan eficaz, como la de saltar al anillo 0, sólo pueda emplearse en la 
práctica con Windows 9x/Me (esto es, no resulta viable programar, por ejemplo, un driver 
SYS propio), reduciendo así la eficacia del número de mecanismos disponibles en los 
sistemas NT. 


MANERAS DE SALTAR ENTRE EL ANILLO 3 Y EL ANILLO 0 


Lista de descriptores locales (LDT) 


Probablemente constituya el método más antiguo de saltar del anillo 3 al anillo 0. 
No merece la pena detenerse en comentar el código, innecesariamente complicado, 
anticuado y en desuso. Ha quedado sustituido por los restantes dos métodos, mucho 
mejores. Se mencionarán aquí sólo con ánimo de ser exhaustivos. 


BYTE Gat [6]; 
eat.[0] = 0; 
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Gat [1] = O 
Gat [2] = O 
Gdt [3] = 0; 
Gdt [4] = O 
Gdt [5] = 0 


BYTE Call_Ring0[6] 
Call_Ring0[0] = 0; 
Call_Ring0[1] = 0; 
Call_Ring0[2] = 0; 
Call_Ring0[3] = 0; 
Call_Ring0[4] = 0xF; 


Call_Ring0[5] = 0; 
BYTE Callgate[8]; 
Callgate[0] = 0; 
Callgate [1] = 0; 
Callgate[2] = 0x28; 
Callgate[3] = 0; 
Callgate[4] = 0; 
Callgate[5] = OxEC; 
Callgate[6] = 0; 
Callgate[7] = 0; 


DWORD Gate = (DWORD) Callgate; 


_asm 
( 
mov ax, ds 
test al,4 
je Not_Win9x 


Win9x: 


mov eax, offset Ringo0 


mov word ptr [Callgate],ax 


shr eax,16 


mov word ptr [Callgate+6],ax 


// ¿sistema operativo? 

// bifurcación si el 
sistema operativo no 
es Windows 9x/Me 


// EAX = dirección de 
la parte del 
programa que se 
ejecutará en el 
anillo 0 

// dirección del 
código que se 
ejecutará en el 
anillo 0 en nuestro 
callgate 
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xor eax,eax 
sgdt fword ptr Gdt 
mov ebx,dword ptr [Gdt+2] 


sldt ax 
add ebx,eax 


mov al, [ebx+4] 
mov ah, [ebx+7] 
shl eax,16 


mov ax, [ebx+2] 


add eax,8 

mov edi,eax 

mov esi,Gate 

movsd 

movsd 

call fword ptr [Call_Ring0] 
xor eax,eax 

sub edi,8 


stosd 


stosd 
jmp Ok 


/¡****x***Anillo QAAAAAAR Y 


Ringo0: 


mov eax,Dr7 


retf 


Not_Win9Xx: 


// se guarda GDT 
// EBX = dirección de 
GDT 


// obtención de la 
dirección del 
descriptor 


// EAX = dirección de 
LDT 

// obtención de la 
dirección del 
descriptor callgate 


// EDI = dirección en 
callgate para 
aplicar cambios 

// ESI = dirección de 
nuestra callgate 

// se sobrescribe el 
anterior callgate 


//--> anillo 0 


// recuperación de la 
anterior callgate 


// esta interrupción 
sólo funcionará en 
el anillo 0 

//-->Anillo 3 


MessageBox ("Éste método sólo funciona con Windows 


9x/Me” ,NULL,MB_OK); 
return; 
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Ok: 
MessageBox (“Cambio de anillo satisfactorio”, 
NULL, MB_0K); 


Lista de descriptores de interrupciones (IDT) 


Representa otro método bien conocido para que el programa salte del anillo 3 al 
anillo 0. Esta técnica se basa en la sustitución de vector, esto es, la sustitución de una 
rutina con ciertos interruptores. La interrupción se ejecutará en el anillo O y si dirigiéramos 
una rutina de interruptores a nuestro propio código, también se ejecutará en el anillo cero. 


La sustitución de vector se utiliza abundantemente en algoritmos antidepuradores de 
todo tipo. Se redirigen las rutinas de interrupción que precisa el depurador (INT1 e INT3), 
lo que complica muchísimo e incluso evita su uso. Resulta, sin embargo, necesario 
considerar que, puesto que el sistema y algunas otras aplicaciones también utilizan algunas 
interrupciones con frecuencia, no se pueden sobrescribir sin más. Siempre habrá de 
restaurar su estado original, sin olvidarse tampoco de la multitarea, el sistema está 
constantemente alternando entre los procesos en ejecución (aunque el usuario los perciba 
como simultáneos): si se desea preservar la integridad, deberá restaurarse la rutina de 
interrupción original antes de que el sistema salte a otro proceso. Resulta decisivo 
recuperar la interrupción pertinente. 


Aunque este método no sea malo, no llega a alcanzar al siguiente basado en SEH. A 
causa, en primer lugar, de los problemas con la redefinición de interrupciones recién 
mencionados, y en segundo, por su fácil detección (véase el capítulo 4, FrogsICE). 


El siguiente programa salta del anillo 3 al anillo O utilizando IDT y la interrupción 


INT3: 
_asm 
( 
mov ax, ds 
test al, 4 // ¿sistema operativo? 
je Not_Win9x // bifurcación = el 
sistema operativo no 
es Windows 9x/Me 
Win9x: 
push edx 
sidt [esp-2] // carga de IDT en la 


pila 
pop edx 


CG RA-MA 


add edx, (3/*=INT 3*/*8)+4 


mov ebx, [edx] 


mov bx,word ptr [edx-4] 


lea edi,Ring0 
mov [edx-4] di 
ror edi,16 


mov [edx+2] di 
push ds 


push es 
INT 3 


pop es 


pop ds 
mov [edx-4],bx 


ror ebx,16 
mov [edx+2] ,bx 
jmp Ok 


JARA RINGO A AAA 


Ringo: 


) 


mov eax,Dr7 


iretd 


Not_Win9x: 
MessageBox (“Este método sólo funciona con Windows 


9x/Me” , NULL, MB_OK); 
return; 
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1! 


A 


// 


EDX = vector de la 
interpretación 
seleccionada, 1.e. 
INT 3 


guardando la 
dirección de la 
rutina de 
interruptores para 
restaurarla 
posteriormente 


redirección de la 
rutina de 
interruptores al 
código propio que 
vaya a ejecutarse en 
el anillo 0 


guardando valores 
importantes de los 
registros 


//-->Anillo 0 


4 


// 


// 


recuperación de los 
registros 


recuperación de la 
anterior rutina de 
interruptores 


esta instrucción 
sólo funcionará en 
el anillo 0 


//-->Anillo 3 
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Ok: 
MessageBox ("Cambio de anillo satisfactorio”, 


NULL, MB_OK) ; 


Gestión estructurada de excepciones (SEH) 


Éste es el tercer y último método para procurar que un programa salte del anillo 3 al 
anillo 0. Es el más difícil de detectar. El programa primero causa una excepción, que 
dispara al manejador, lo que brinda la posibilidad de ajustar todos los registros y valores 
elegantemente, de manera que al devolver el control el manejador al programa, éste se 
ejecuta en el anillo cero. 


Merece la pena destacar, que si bien el método resultaba muy dificil de detectar, no 
debe emplearse la instrucción INT3 para crear la excepción. Algo, que a estas alturas, el 
lector debe ya conocer, 


_asm 
mov ax,ds 
test al,4 
je Not_Win9x 


// ¿sistema operativo? 

// bifurcación = el 
sistema operativo no 
es Windows 9x/Me 


Win9x: 


push offset MyHandler // guardando la 


dirección de nuestro 
manejador 


// guardando la 
dirección del 
manejador anterior 


push dword ptr fs: [0] 


mov fs: [0] ,esp 
pushfd 
mov eax, esp 


INT 3 


// instalación 

// guardando EFLAGS 

// guardando el valor 
ESP, esto es, la 
dirección de la pila 

//-->Anillo 0 

// innecesario aquí 
NOP - el código se 
ejecuta sólo en 
Windows 9x//Me 
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// el manejador no 
necesita restaurar 
la excepción ( 
saltándola modifica 
el valor ElIP) 
provocada, ya que 
EIP, en Windows 
9x/Me señala a la 
instrucción 
siguiente a INT 3 


[ARARAAARÍNGO A AAA AS 

mov ebx,Dr7 // esta instrucción 
sólo funcionará en 
el anillo 0 


// recuperación de los 
valores anteriores 
de los registros 
antes de saltar al 


anillo 3 
push edx // GS 
push edx // FS 
push edx // ES 
push edx // DS 
push edx 7/1 Ss 
push eax // ESP 
push dword ptr [eax] // EFLAGS 
push ecx £/ es 
push offset Ring3 // EIP = dirección del 


código donde el 
programa se 
ejecutará en el 
anillo 3 de nuevo 


iretd //-->Anillo 3 
Ring3: 
poptd // recuperación de 
EFLAGS 
pop dword ptr fs: [0] // recuperación del 
manejador anterior 
add esp,4 // ajuste de pila 


jmp Ok 
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[ARK *MyHandler***x*x*x*x/ 
// manejador SEH para 
saltar al anillo O 


MyHandler: 

mov edx, [esp+0Ch] // CONTEXT 

mov ecx, [esp+4] // EXCEPTION_RECORD 

mov ecx, [ecx] // ECX = valor de la 
excepción recién | 
ocurrida 

cmp ecx,80000003h // ¿causó INT3 la 
excepción 


STATUS _BREAKPOINT 
(80000003h) ? 

jne Error // bifurcación = se 
produjo otra 
excepción que no 
procesará este 


manejador 
mMOVZX ecx,word ptr [edx+0BCh] // ECX = CS 
mov [edx+0ACh] ,ecx // ECX(tras la 


bifurcación desde el 
manejador, vuelta al 
código del programa) 


= CS 
mov dword ptr [edx+0BCh],28h // CS(tras la 
bifurcación ...) = 
28h, para saltar al 
anillo 0 
MOVZX ecx,word ptr [edx+0C8h] // ECX = SS 
mov [edx+0A8h] ,ecx // EDX(tras la 
bifurcación ...) = 
ECX = SS 
mov dword ptr [edx+0C8h],30h // SS(tras la 
bifurcación...) = 
30h, para saltar al 
anillo 0 
or dword ptr [edx+0C0h],200h // EFLAGS (tras la 
bifurcación...) = 
200h 
sub eax,eax 194 | 
ExceptionContinueExecution 
ret //--> anillo 0 
Error: 
sub eax, eax 
inc eax 1/ 
ExceptionContinueSearch 
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MessageBox (“Este método sólo funciona con Windows 


ret 

) 

Not_Win9x: 
9x/Me” NULL,MB_OK); 
return; 

Ok: 


MessageBox (“Cambio de anillo satisfactorio”, 


NULL, MB_0K); 


Detección de SoftICE mediante VxDCall 


El próximo método de detección de un SoftICE activo resulta muy semejante al que 
emplea la función API CreateFileA. De nuevo se intentará acceder a los drivers de 
SoftICE, en este caso mediante VxDCall. Estas llamadas las realizan los drivers lógicos 
(librerías VxD) únicamente desde el anillo 0. Por esta razón, el método sólo se puede 
utilizar con Windows 9x/Me. Se invocará la función VVMMCal1 Get_DDB para saber si 


un driver específico se ha guardado o no en memoria. 


A un driver se le identifica o por su nombre o por su identificador. Aquí se eligirá el 
identificador: 202h, para el driver denominado SICE. También se pueden utilizar otros 
drivers para la detección, por ejemplo, el driver gráfico denominado SIWVID, cuyo 
identificador es 7ASFh. Cuando la detección sea difícil, se aplicará el método SEH para 


saltar al anillo 0. 


DWORD ID = 0x202; 
// DWORD ID = Ox7A5F; 
DWORD Name = 0; 


_asm 
mov ax,ds 
test al,4 
je Not_Win9x 


Win9x: 
push offset MyHandler 


// 
// 
// 


// 
// 


// 


SICE 

SIWVID 

innecesario definir 
nombre 


¿sistema operativo? 
bifurcación = el 
sistema operativo no 
es Windows 9x/Me 


guardando la 
dirección de nuestro 
manejador 
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push dword ptr fs:[0] // guardando la 
dirección del 
manejador anterior 


mov fs: [0],esp // instalación 
pushfd 
mov eax,esp 
INT 3 //--> anillo 0 
// NOP innecesario 
aquí 


/*******Anillo A 
push edx 

push edx 

push edx 

push edx 

push edx 

push eax 

push dword ptr [eax] 
push ecx 

push offset Ring3 


mov eax, 1D // EAX = identificador 
del driver 

mov edi ,Name // EDI = nombre del 
driver 


[*ARARARVXDCAL]AAAAAA AS 


__emit 0xCD // VMMCall Get_DDB 

_ emit 0x20 1/ 

_ emit 0x46 // 

_ emit 1 1/ 

_ emit 1 del 

_ emit 0 // 

test ecx,ecx // ¿detectado driver? 

jz Not_Detected 

xor eax,eax // en caso afirmativo, 
EAX = 0 


Not_Detected: 


iretd //--> Anillo 3 
Ring3: 

popfd 

pop dword ptr fs: [0] // recuperación del 


manejador anterior 


ORA-MA 
add esp,4 // ajuste de pila 
test eax,eax // ¿driver detectado? 


jnz No_SoftICE 
jmp SoftICE 


[RARA RA My Handler *** xxx / 


// manejador SEH para 
saltar al anillo O 


MyHandler: 

mov edx, [esp+0Ch] // CONTEXT 

mov ecx, lesp+4] // EXCEPTION_RECORD 

mov ecx, [ecx] // ECX = valor de la 
excepción recién 
ocurrida 

cmp ecx,80000003h // ¿causó INT3 la 
excepción 


STATUS_BREAKPOINT 
(80000003h) ? 

jne Error +: // bifurcación = se 
produjo otra 
excepción que no 
procesará este 


manejador 
movzx ecx,word ptr [edx+0BCh] 
mov [edx+0ACh] ,ecx 
mov dword ptr [edx+0BCh],28h 
movzx ecx,word ptr [edx+0C8h] 
mov [edx+0A8h] ,ecx 
mov dword ptr [edx+0C8h],30h 
or dword ptr [edx+0C0h],200h 
sub eax,eax // ExceptionContinueExecution 
ret //--> anillo 0 
Error: 
sub eax,eax 
inc eax // ExceptionContinueSearch 
ret 
A 
Not_Win9x: 
MessageBox (“Este método sólo funciona con Windows 9x/Me 
" ¡NULL,MB_OK); 
return; 
No_SOoftICE: 


MessageBox ("SoftICE no detectado” ,NULL,MB_O0K); 
return; 
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SoftICE: 
MessageBox ("SoftICE detectado” ,NULL,MB_0K); 


Desactivación de la tecla de atención de SoftlCE 


En último lugar se describe este método para detectar un SoftICE activo, un 
verdadero placer para un autor cuyo apodo es “trapflag”. Este método consiste en intentar 
localizar los drivers de SoftICE que controlan su tecla de atención para mostrar el 
programa (Ctrl+D por omisión). Si los drivers se localizan, la instrucción correspondiente 
se sobrescribirá y la tecla de atención quedaría desactivada (además, se informa mediante 
un mensaje que SoftICE se ha desactivado, se aconseja suprimirlo y no informar al usuario 
de nada). Con este propósito se utiliza una librería VxD (aquí no resulta muy sensato 
utilizar VxDCall, tampoco resulta práctico emplear un driver SYS con Windows 
NT/2000/XP), que restringe el uso del método a Windows 9x/Me. Otro obstáculo radica 
en la presencia de la propia librería VxD. Una librería de este tipo dentro del programa 
junto a la desactivación de la tecla de atención de SoftICE, constituye una pista para que el 
cracker sepa lo que ha sucedido. Es más, puesto que todo el control de la librería se ciñe a 
su llamada a la función API CreateFileA, se podría suprimir con sencillez, Resulta 
necesario enmascarar la librería y, si fuera posible, su contenido. Resulta de gran ayuda el 
que la aplicación utilice librerías VxD para otros cometidos. (Elíjase un nombre apropiado 
para la librería, y no algo como ¡AntiSoftICE.VxD!) La mejor manera consiste en integrar 
la función dentro de otra librería VxD del programa, así el cracker que suprima la 
invocación a la librería mediante la función AP] CreateFileA provocará una excepción 
distinta en el programa. 


A continuación se muestra el código de la librería VxD (original de “trapflag” con 
comentarios traducidos): 


; detector y supresor de SOFTICE by trapflag 

; esta vxd detectará softice en memoria y deshabilitará 
; su manejador de la tecla de atención - actualmente 

; con dos NOPs, así sice será aún accesible ( mediante 
; puntos de corte y etc.) también se puede parchear 

¿ con EBFE.. 

; si vas a utilizar mi código en tus programas, 

; indícalo y envíame una copia de tus programas. 

; saludos a the owl por su ayuda. 

; trapflagabacktrace.de 


.486p 
include vmm.inc 

include vwin32.inc 
include shell.inc 
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DECLARE VIRTUAL DEVI CE 
DBG,1,0,DBG_ Control, UNDEFINED_DEVICE_ID, UNDEFINED_INIT_O 
RDER 
; mensajes que se deben tratar 
Begin _control_dispatch DBG 
Control _Dispatch Sys Dynamic _Device_Init, 
OnDeviceInit Control_Dispatch 
Sys Dynamic Device Exit, 
OnDeviceDestroy Control _Dispatch 
w32 DeviceloControl,OnDeviceloControl 
End _control_dispatch DBG 
A sI pin ER 
; Segmento de datos bloqueado 


VxD_LOCKED_DATA_SEG 
; algunas variables 


sequence db 0e4h,060h ; código (opcode) 60 del 
"manejador de la tecla de 
; atención" de SoftICE 


Message db '¡SoftlIce detectado y suprimido!',0 
Caption db 0 

pszName db 80 dup(0) 

scasb_exception Exception _Handler_Struc <> 


VxD_LOCKED_DATA_ENDS 


; Segmento de código bloqueado 


VxD_PAGEABLE_CODE_SEG 


BeginProc OnDevicelInit ; si el usuario carga el 
; dispositivo int 3 


mov scask exception.EH_ Reserved, 0 

mov scasb _exception.EH_Start_EIP,offset32 
scasb_protect 

mov scasb_exception.EH_End_EIP,offset32 
scasbh_endprotect 

mov scasb _exception.EH Handler, offset32 EHandler 
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mov esi, offset32 scasb exception 
VMMCall Install_Exception Handler ¡; Manejador de 
; excepciones para tratar 
; los errores de página 
cld 
mov edi, 0C0000000h ; dirección base 
; para la región 
¡; Compartida del sistema 
; aquí se suspenden las vxds 
mov ecx, OFFFFFh ; exploración de los 
¡primeros OO00OFFFFFh bytes 


seek: 
mov al,0ldh ; búsqueda de l1dh 
mov esi,offset32 sequence ¡esi= apunta a opcodes del 
¡; Manejador de la tecla de atención 
scasb protect: 
repne scasb ; búsqueda de [edi] 
scasb_endprotect : 
test ecx,ecx ¡¿counter=0 ? 
jz exit ¡salir 
push edi ¡guardar edi 
push ecx ¡e incluso ecx 
add  edi,4 ¡edi=edi+4 
mov  ecx,2 ¡compara 2 bytes de [esi] 
¡a [edi] 
repe cmpsb ln 
pop  ecx ¡recupera el mayor mr ecx 
pop edi ¡¿su secuencia relativa no 
¡fue el manejador de la 
jnz seek ¡; tecla de atención de 
¡sice? 
¡=> buscar 
add  edi,4 ¡; secuencia de byte/ 
¡manejador detectado 
¿int 3 


mov word ptr [edi],09090H ¡ dando un toque 
¡; Maligno al manejador de la tecla de atención 


xor ebx, ebx ; Manejo máquina virtual 
mov eax, MB_SYSTEMMODAL ; flags de mensajes 
mov ecx, OFFSET32 Message ; dirección del 
¡; mensaje 
mov edi, OFFSET32 Caption ; dirección de 
¡Caption 


VxDcall SHELL SYSMODAL Message ¡; mostrar mensaje 
; => sice detectado 
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exit: 
A a 
ole 
ret ¡; volver al cargador 
EHandler: 
sunt: 3 
test ecx,ecx sé fin de la búsqueda? 
jz exit ¡sí, salir 
dec ecx ¡¿no, entonces contador dec 
inc edi ¡inc puntero 


jmp scasb protect; seguir buscando 
EndProc OnDevicelnit 


BeginProc OnDeviceDestroy ; si el usuario descarga 
; el dispositivo 


elo 
ret 
EndProc OnDeviceDestroy 


BeginProc OnDeviceloControl ¡DEBE manejarse 
assume esi:ptr DIOCParams 
.IF [esi].dwlIoControlCode == DIOC_Open 
xor  eax,eax 
.ENDIF 
ret 
EndProc OnDeviceloControl 


VxD_PAGEABLE_CODE_ENDS 


End 


OTROS USOS SENCILLOS DE SEH 


En el ejemplo anterior se describía cómo detectar y desactivar la tecla de atención 
de SOftICE. Existen otras alternativas de enfrentarse al problema. Dicha combinación de 
teclas también se puede emplear para otros objetivos. La tecla de atención que invoca al 
programa SoftICE sustituye a todas las otras teclas de atención. Si en una aplicación se 
asignase una función importante a esta tecla de atención que además no pudiera arrancarse 
de otro modo (por ejemplo, mostrar la ventana de registro de un programa), se ejecutaría 
SoftICE en vez de la función de dicha aplicación y, por tanto, no se podría depurar nada. 
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No representa ningún obstáculo modificar la teclas de atención (tampoco en el caso de 
Windows NT/2000/XP, puesto que SoftICE se puede arrancar como un servicio y no antes 
del propio Windows como sucede con Windows 9x/Me), si bien resulta bastante 
incómodo. A continuación se muestra el código: 


if ((GetAsyncKeyState (VK_CONTROL) € 
0x8000)8£8 (GetAsyncKeyState('D') £ 
0x8000)£8 (GetActiveWindow() == this)) 


( 


// función importante 
- por ejemplo, 
arranque de la 
ventana de registro 
de la aplicación 


Defínase la función para que procese el mensaje WM_TIMBR. Sólo restará definir el 
contador mediante la función “SetTimer (por ejemplo, en la función 
OnInitDialog()): 


SetTimer (1234,100,NULL); // definición de 
contador 


No hay que creerse que métodos primitivos como éste detendrán a un cracker, pero 
al menos le contrariarán un poco. Aún no ha visto este autor llevar a la práctica este 
método de protección. No obstante, existe un programa en Internet cuya tecla de atención 
“secreta” se revela tras pagar por registrarse. No es una mala idea. 


El lector habrá podido apreciar en los modelos anteriores algunas propiedades muy 
interesantes de SEH, 


Por ejemplo, la modificación del registro EIP (en el manejador), que sirve para 
sortear la instrucción incorrecta en nuestro ejemplo, puede utilizarse para bifurcaciones 
mucho más largas en vez de tratar las excepciones: bifurcaciones “imperceptibles” en el 
código del programa. Únicamente ha de enmascararse la operación dentro del código y así 
poder saltar de una función a otra sin que nadie lo aprecie a primera vista (naturalmente no 
en un código de varias líneas). 


Si se tratase de depurar el ejemplo dado para detectar el punto de corte hardware, se 
observará algo realmente interesante. En el momento en el que el depurador llega a una de 
las instrucciones NOP donde se define el punto de corte, el depurador se detiene —queda 
“bloqueado” de algún modo—. Razón por la que se ha de considerar la definición de 
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puntos de corte en instrucciones NOP no críticas repartidas por el código con ánimo de 
dificultar más la depuración. Aún queda algún otro consejo que aportar antes de proceder 
con el siguiente capítulo. 


No debe nunca olvidarse que aunque se utilice SEH en beneficio propio, también se 
puede emplear en nuestra contra, Afirmación que queda bien ilustrada en el caso de las 
protecciones comerciales Armadillo y VBox. En ambos casos combinan la invocación a 
INT3 con la función API SetUnhandledExceptionFilter para detectar el 
depurador activo. Sus autores, obviamente, no invirtieron mucho tiempo ni esfuerzo en el 
diseño de la protección, puesto que el manejador no distingue ninguna excepción en 
particular. Se asume que la causa de todas las excepciones sea la instrucción INT3, esto es, 
depurador inactivo. Pero, ¿qué sucedería si alguien causara una excepción adrede? Los 
autores del sistema de protección no consideraron esta posibilidad, así que sólo resta 
causar una excepción en el programa para, paradójicamente, sortear su mecanismo de 
protección. En conclusión: siempre habrán de extremarse las precauciones con el 
manejador y nunca olvidar verificar la idoneidad (¡verdadera ironía!) de las posibles 
excepciones y comprobar los valores obtenidos, por ejemplo, al invocar INT3 en 
combinación con la interfaz BoundsChecker, 


la 


CAPÍTULO 3 


PROTECCIÓN CONTRA LOS 
DESENSAMBLADORES 


Ya se ha definido anteriormente el concepto de desensamblaje: se trata de 
analizar un programa hasta revertirlo a su código ensamblador original. Resulta 
especialmente útil al tratar de entender la lógica de ciertos algoritmos. También sirve 
para orientarse dentro del programa y, sobre todo, para buscar cadenas de caracteres, 
funciones importadas, posiciones en un programa e identificar dónde se invocan y 
cómo se emplean. 


La causa principal de la gran difusión de los desensambladores radica en su 
capacidad para buscar dentro de un programa cadenas de caracteres y funciones 
importadas. Gracias a estas propiedades, un cracker puede aproximarse casi 
inmediatamente al algoritmo de protección y estudiarlo sin dificultar y, por 
consiguiente, anularlo. Todo ello convierte a los desensambladores en armas 
tremendamente potentes, incluso en las manos de un principiante. 


DESENSAMBLADORES HABITUALES 


Desde el advenimiento del cracking, existen dos programas prácticamente 
considerados estándares en el campo del desensamblaje: W32Dasm e IDA. Por 
supuesto, hay muchos otros, pero W32Dasm e IDA son sencillamente los 
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desensambladores más habituales hoy en día. A pesar de que W32Dasm se ha quedado 
anticuado, de que se abandonó su desarrollo y de que puede parecer inmanejable en la 
práctica, los crackers aún lo utilizan con mucha frecuencia. Lo aceptaron de tal modo 
que aunque en realidad se haya paralizado su desarrollo, ellos continúan desarrollando 
mejoras, actualizaciones y parches (incluidos en el CD adjunto). Realmente constituye 
un ejemplo perfecto de cómo aplicar la ingeniería inversa para mejorar un programa. 


W32Dasm resulta bastante accesible para todo tipo de usuarios. Aunque 
no se pueda personalizar mucho el proceso de desensamblaje y configuración, 
para compensar, el programa resulta muy sencillo e intuitivo, con una buena 
presentación del código ensamblador resultante. El programa incluye un cuadro 
de referencias de cadenas y funciones importadas, una utilidad para buscar 
texto, y muchas otras propiedades que facilitan enormemente la búsqueda y el 
análisis de un programa. Una vez aplicado el mantenimiento, el programa 
incorporará otras características, como un editor hexadecimal. En la siguiente 
sección se describe el uso de esta herramienta. 


IDA (Interactive DisAssembler”, en inglés) constituye, como su nombre 
indica, una herramienta completa de desensamblaje profesional totalmente 
configurable. Rey indiscutible de los desensambladores, con sus opciones y 
características, no tiene rival en su campo. La increíble flexibilidad de este 
producto (con la posibilidad de programar en un lenguaje semejante a C) 
permite desensamblar correctamente programas inasequibles para W32Dasm. El 
proceso de desensamblaje también se puede adaptar y controlar manualmente 
de muchos modos. Su flexibilidad se demuestra, sin embargo, en las 
modificaciones que el usuario puede realizar durante el proceso, lo que a 
primera vista podría parecer algo complejo y enrevesado. El programa está 
destinado para usuarios más avanzados y no para principiantes. 


USO ELEMENTAL DE W32DASM 


Su entorno de trabajo parece muy organizado y bien dispuesto. El primer paso 
consiste en elegir el fichero que se desea desensamblar: selecciónese la opción “Open 
File to Disassemble” del menú “Disassembler”. Tras desensamblar el fichero elegido 
(su duración dependerá del tamaño del fichero), quedarán activadas otras opciones del 
programa. 
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URSOfEW: 


Figura 3-1. Entorno de trabajo del desensamblador W32Dasm 


Pulsando la tecla F1O, o el botón “Goto Program Entry Point”, se accede al punto de 
entrada del código desensamblado del programa (véase el capítulo 7 sobre el formato PE si 
se desea más detalles). Igualmente se puede acceder a cualquier otra dirección pulsando la 
tecla de mayúsculas y F12 o bien el botón “Goto Code Location”. 


Se puede acceder a la lista de funciones importadas pulsando el botón “Imports”, y a 
la lista de funciones exportadas pulsando el botón “Exports”. 


w32Dasm Alphabetical List of Imported funcions 


Figura 3-2. Lista de funciones importadas 
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Cuando se pulsa en una función APT, se accede a la ubicación dentro del programa 
desde donde se realiza su invocación. Si esta función se invocase varias veces, al pulsar en 
ella seguidamente, se recorrerían todas las direcciones de acceso a la función. 


Selecciónese “String Data References” si se desea obtener la lista de cadenas de 
caracteres. Aquí se pueden encontrar cadenas muy interesantes que conducen directamente 
al corazón del algoritmo de protección. Si se tratase de desensamblar un programa de 
código compartido, probablemente se hallaría una indicación con datos sobre el registro 
incorrecta o correctamente realizado, etc. 


W32Dasm List of String Data Items 


To Search Disassembly for Sting Data, Double Chick on Text Cancel Search 


"CrackMe v1.0" 
"Good work!" 
"Great wotk, matel"" 

"MENU" 

"No luck there, mate!" 

"No luck” 

"No need lo disasm the codel'" 


CopyAl | CopyView 


Figura 3-3. Lista de cadena de caracteres muy sugerente 


Las cadenas de caracteres se manejan de forma muy similar a como se hace con las 
funciones importadas: basta con pulsar en cualquier cadena para saltar al código 
desensamblado que la emplee de algún modo. 


Resulta muy sencillo analizar y trabajar con el propio código del programa 
desensamblado. Las referencias a instrucciones tipo “jump” y “CALL” quedan destacadas 
en el código, de modo que resulta muy fácil orientarse incluso con los algoritmos más 
complicados. Una franja azul destaca la instrucción presente. 


Pulsando la flecha hacia la derecha se pueden rastrear los saltos condicionados y no 
condicionados, así como las instrucciones “CALL” (o bien pulsando el botón “Jump to”, o 
en el caso de las instrucciones CALL, el botón “Call”). Pulsando la fecha hacia la 
izquierda (o la tecla intro) se vuelve a la instrucción CALL. Para los saltos utilícese 
Control+ flecha hacia la izquierda (o el botón “Ret JMP”). 


En caso de trabajar frecuentemente con ficheros grandes cuyo desensamblaje 
consume mucho tiempo, resulta más práctico guardar los ficheros en código de 
ensamblado. Para ello, selecciónese la opción “Save Disassembly text File and Create 
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Project File” del menú “Disassembler”. Siempre se podrá cargar un fichero desde el menú 
“Project” con la opción “Open Project File”. 


Con esto termina la introducción a las características básicas de W32Dasm. Por su 
sencillez y comodidad, el lector podrá descubrir por sí mismo otras características del 
programa, No se describirá aquí su uso como depurador, puesto que ni se acerca a la 
calidad de SoftICE. 


ALGORITMOS COMUNES 


Al igual que sucedía con los mecanismos antidepuradores, los programas han de 
protegerse contra algunas de las características de los desensambladores o contra el 
desensamblaje en su totalidad. Si con el primero el programa se defendía detectando 
depuradores activos, puntos de corte, etc. (en este capítulo se introducirán algunos métodos 
antidepuradores que dificultarán aún más la tarea al depurador), con los mecanismos 
antidesensamblaje no se podrá proceder de igual manera. La razón de ello estriba en que, 
al igual que sucede cuando se edita el código de un programa con un editor hexadecimal, 
el programa no se ejecuta y, por tanto, sólo puede protegerse pasivamente. Aunque sea 
posible la detección activa (por ejemplo, buscando los nombres de los procesos, ventanas, 
etc. en ejecución), resulta prácticamente estéril (eso sin considerar el hecho de que, a 
diferencia de SoftICE, existen muchísimos desensambladores y editores hexadecimales). 


Hace un par de años, cuando la calidad de los desensambladores no llegaba al nivel 
de hoy en día, resultaba muy sencillo proteger a los programas del desensamblaje. Se 
incluían en el código del programa algoritmos y secuencias de instrucciones que el 
compilador nunca llegaría a generar. De manera que al intentar la descompilación se 
producía un error o un bucle infinito, He aquí un ejemplo de estas instrucciones “confusas” 
que se empleaban con frecuencia en el pasado: 


mov eax,123456h 
push eax 
ret 


Este código, de hecho, es equivalente a las instrucciones JMP EAX, y aún se puede 
hallar de varias formas en numerosos mecanismos de protección. 


Hoy en día, los desensambladores están preparados frente a tales tácticas, 
reduciendo todas las garantías de éxito de esta técnica. Hay que procurar volver inútil la 
tarea de desensamblar un fichero. Se podrá desensamblar el fichero, pero el código 
resultante o bien no tendrá ningún sentido, o bien estará tan desordenado que resultará 
inmanejable para cualquier análisis. Posteriormente se examinará con más detalle esta 
técnica. A continuación se describirán los mecanismos de protección frente a las 
propiedades más peligrosas de los desensambladores, por ejemplo, las referencias a las 
cadenas de caracteres y funciones importadas. 
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Protección contra las cadenas 


Resulta muy sencillo evitar que otros busquen cadenas de caracteres en un 
programa. Basta con cifrarlos (aparecerán caracteres sin sentido en vez de los esperados, 
completamente inútiles para un cracker) modificarlos de alguna manera, o 
preferentemente evitar su uso enteramente si fuera posible. Existen muchas formas de 
guardar texto en un fichero... 


Protección contra las funciones importadas 


Los desensambladores emplean una tabla especial, denominada tabla de 
importaciones, para crear la lista de funciones importadas que apuntan a ciertas 
ubicaciones dentro del programa. En el capítulo 7, acerca del formato PE, aplicado en la 
mayoría de los métodos de protección contra funciones importadas, se abundará más en su 
estructura exacta, funciones y protección. Bastará ahora con detallar las técnicas más 
simples, basadas enteramente en llamadas indirectas a funciones y en invocaciones hechas 
de tal forma que a la hora de importarlas, el compilador no las puede tratar de ninguna 
manera (al intentar insertarlas en la tabla de importaciones). Las funciones invocadas de 
este modo no se describen en la tabla de importaciones con lo que el desensamblador no 
podrá mostrarlas en su lista. 


Esta técnica resulta útil principalmente con las funciones API, donde en la mayoría 
de los casos no hay necesidad de cargar la librería que queremos “importar” manualmente 
de la memoria (mediante la función API LoadLibraryA) puesto que normalmente ya la 
está utilizando el proceso. 


El primer paso consiste en localizar la imagen de la librería cargada (véase el 
capítulo 7), donde se ubica la función solicitada. A continuación se calcula su dirección, y 
se accede a ella directamente. 


En este ejemplo se localiza la dirección de la función CreateFileA en la librería 
kernel32.dl. Es muy simple: 


GetModuleHandle ("kernel32"); 
// imageBase kernel32 
GetProcAddress (Handle, "CreateFileA”); 
// dirección de la 
// función CreateFilea 


HMODULE Handle 


'" 


FARPROC Create 


A continuación se procede invocando a la función, por ejemplo: 


1] 
a 
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asm 


A 


push 0 

push FILE_ATTRIBUTE_NORMAL 

push OPEN_EXISTING 

push 0 

push FILE _SHARE_READ 

push GENERIC_READ 

push pointer_on file name 

call Create // CALL CreateFileA 
mov File Handle, eax 


// HANDLE File Handle = 
CreateFile (“file _name",GENERIC_READ, FILE_SHARE_READ, 
NULL, OPEN_EXISTING, FILE ATTRIBUTE_NORMAL, NULL); 


Esta técnica en sí es muy vulnerable por lo fácil que resulta identificar la 
combinación de las bien conocidas funciones “GetModuleHandleA” y 
“GetProcaAdress” en la tabla de funciones importadas. Es más, aún puede encontrarse 
en la lista de caracteres los nombres de las funciones y de la librería, lo que no pasará 
desapercibido. Resulta preferible combinar esta técnica con otras relativas a las funciones 
importadas y a la protección de cadenas de caracteres. 


Este método de protección es mucho más frecuente: la dirección de las funciones 
importadas se guardan en un sitio (ya sea utilizando la tabla de importaciones o no) al que 
se invoca desde otro lugar del código. Ésta es una entre tantas maneras de evitar a los 
desensambladores mostrar la función importada: guardándola en un sitio inhabitual. 


En cualquiera de los ejemplos del capítulo 9 se podrá observar el uso de los 
métodos anteriormente mencionados. 


CÓDIGO AUTOMODIFICABLE (SMC) 


SMC constituye uno de los métodos de protección de software más utilizados que, 
además, excede el ámbito del desensamblaje. Puede parecer un poco forzado incluir esta 
técnica en el capítulo sobre antidesensamblaje, pero téngase en cuenta que muchas técnicas 
de cracking se complementan y se solapan, volviendo indistinguibles las fronteras entre 
ellas. Por otra parte, algunas técnicas antidesensamblaje realmente funcionan como 
antidepuradores, y viceversa. Resulta más cierto aún en el caso de SMC, Obstaculiza la 
edición del código del programa así como su depurado y desensamblado, incluso lo 
imposibilita totalmente. Hay dos tipos de SMC: el primero emplea generación (edición) 
dinámica completa del código del programa durante su ejecución; el segundo saca partido 
de las múltiples formas de expresar código en ensamblador. Con objeto de simplificar, al 
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primero se denominará SMC activo y al segundo SMC pasivo. No obstante, éstos no son 
términos oficiales. 


SMC Pasivo 


Obsérvese el siguiente ejemplo: 


:00401000 EBO01 jmp 00401003 
:00401002 E86641 call xxxxXx (El parámetro de esta instrucción no es inportante) 
:00401005 


Se habrá observado algo muy extraño: ¡la primera instrucción JMP salta a algún 
punto en mitad de la siguiente instrucción CALL! se salta un byte en la dirección 
00401002. El código realmente queda de la siguiente manera: 


:00401000 EB01 jmp 00401003 
:00401002 E8 // saltada esta instrucción incorrecta. 
:00401003 6641 inc eax 


A partir de este sencillo ejemplo, resulta fácil entender en qué consiste y cómo 
funciona el SMC pasivo. Con este tipo de instrucción se pueden obtener resultados 
deslumbrantes. El código queda muy desordenado y dificulta terriblemente su depurado y 
desensamblado. También entorpece muchísimo la edición del propio código del programa. 
Resulta muy ardua la tarea de entender la estructura de dicho código. 


No existen consejos generales para crear algoritmos SMC, Exige cierta cantidad de 
tiempo, paciencia y experiencia. 


El siguiente ejemplo ilustra este tipo de código: 


:00401000 EB01 jmps 000401003 

:00401002 2853BB sub [ebx] [-0045], dl 

:00401005 7856 js 00040105D 

:00401007 3412 xor al, 012 

:00401009 EB15 jmps 000401020 

:0040100B 2881F3214365 sub [ecx] [0654321F3],al 
:00401011 87EB xchg ebp,ebx 

:00401013 02E8 add ch,al 

:00401015 6981F35815519590EB04 imul eax,d, lecx] [0511558F3] , OO4EB9 
:0040101F C2EBEA retn OEAEB 

:00401022 B48B mov ah, 08B 

:00401024 C3 retn 

:00401025 5B pop ebx 
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¿Se podría afirmar que lo único que este código realiza consiste en insertar el valor 
L en el registro EAS? Probablemente no. Examinemos la secuencia de cambios producidos 
en el código conforme se procesa, 


Tras el primer salto a la dirección 00401000, el código se transforma de la siguiente 
manera: 


:00401003 push ebx 

:00401004 mov ebx,12345678 
:00401009 jmp 00401020 
:0040100B sub [ecx+654321F3],al 
:00401011 xchg ebp, ebx 
:00401013 add ch,al 

:00401015 imul eax, lecx+511558F3] ,04EB9095 
:0040101F ret eaeb 

:00401022 mov ah,8B 

:00401024 ret 

:00401025 pop ebx 


Se ejecutan las instrucciones de las direcciones 00401003 y 00401004 y se salta a 
00401020. Tras este salto el código queda así: 


:00401020 jmp 0040100€ 
:00401022 mov ah, 8B 
:00401024 ret 
:00401025 pop ebx 


A continuación se vuelve a la dirección 0040100C: 


:0040100C xor ebx,87654321 
:00401012 jmp 00401016 
:00401014 call 59339182 
:00401019 adc eax,EB909551 
:0040101E add al,c2 
:00401020 jmp 0040100C 
:00401022 mov ah,8B 
:00401024 ret 

:00401025 pop ebx 
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Tras procesar las instrucciones en la dirección 0040100C se produce otro salto, esta 
vez a 00401016: 

:00401016 xor ebx, 95511558 

:0040101C nop 

:0040101D jmp 00401023 

:0040101F ret eaeb 

:00401022 mov ah, 8B 

:00401024 ret 

:00401025 pop ebx 


Y tras el salto final a 0040101D: 


:00401023 mov eax, ebx 
:00401025 pop ebx 


Si se sobrescribieran todas las instrucciones “reales”, se obtendría el código 
siguiente, a partir del cual no resulta difícil entender cómo funciona el algoritmo: 


push ebx // saves EBX 

mov ebx,12345678h // EBX 12345678h 
xor ebx,87654321h // EBX = 95511559h 
xor ebx,95511558h // EBX AL 

mov eax,ebx // EAX = EBX = 1 

pop ebx // recupera EBX 


$" 


El código entero equivale a la instrucción MOV EAX, 1. 


Gracias al uso de SMC y a la utilización de un mayor número de instrucciones para 
ejecutar una tarea dada (en vez de la sencilla MOV EAX, 1), la tarea más simple, como 
guardar el valor 1 en el registro EAX, llega a convertirse en una operación compleja y muy 
desordenada. Se hace muy difícil entender la estructura de semejante código. Con 
algoritmos más largos, y sin un depurador, en ocasiones puede resultar imposible. 


El anterior ejemplo no sólo tiene como objeto mostrar el uso práctico del SMC, sino 
también enseña que no es mala idea en ocasiones escribir algo simple de manera más 
complicada. Juzgue el lector por sí mismo el resultado y el éxito de ambas técnicas. 
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SMC Activo 


La generación dinámica de código constituye una de las mejores maneras de 
proteger el código de programa. Ya se recomendó este método al principio del primer 
capítulo, ahora se describirá y definirá con mayor detalle. Si bien éste no es su lugar 
idóneo, esta técnica merecería un capítulo integro. 


Realmente consiste en editar el código del programa en memoria durante su 
ejecución. Al igual que en ella se escriben variables, registros, etc. también se puede 
escribir el código del programa. El único problema radica en que el segmento de memoria 
empleado para escribir debe tener características de escritura, en caso contrario provoca el 
error “STATUS ACCSESS VIOLATION”. Asunto relacionado con el formato PE, del 
cual se encontrará más información en el capítulo pertinente. Bastará con utilizar la 
función “VirtualProtect” que, con los parámetros oportunos, sí permitirá escribir el 
código de programa ejecutable. 


Con un sencillo ejemplo que ¡lustre las posibilidades y potencia reales del SMC. 
Tras echar una ojeada al código siguiente, el lector podrá con seguridad entender su 
cometido: 


BOOL A = TRUE; 
if (A) 
MessageBox ("El código del programa no se ha 
modificado" ,NULL,MB_OK) ; 
else 
MessageBox ("El código del programa se ha modificado 
con éxito",NULL,MB_0K) ; 


El bucle causado por “else” resulta lógicamente superfluo: siempre se mostrará el 
mensaje “El código del programa no se ha modificado”. Con ensamblador se puede 
escribir el código del ejemplo de la siguiente forma: 


asm 


( 


mov eax,1 

cmp eax,1 

jnz SMC_ 

) 
MessageBox ("El código del programa no se ha 
modificado ",NULL,MB_OK); 
return; 
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SMC 


MessageBox ("El código del programa se ha modificado 
con éxito ",NULL,MB_O0K); 


Seguidamente se puede incluir la llamada a la función “VirtualProtect” en el 
programa y sustituir la instrucción JNZ en su contraria lógica JZ. Al hacerlo, invertimos la 
lógica del algoritmo entero para llegar a ejecutar MessageBox con el parámetro “El código 
del programa se ha modificado con éxito”. Éste sería el resultado: 


DWORD Address,LastProtect; 


_ asm 
mov Address,offset Overwrite 
VirtualProtect 
((void*) Address,10,PAGE_READWRITE, LastProtect) ; 
__asm 
( 


mov ebx, Address 
mov byte ptr [ebx],74h // El valor 75h (instrucción 
//INZ) modificado a 74h (JUZ) 
mov eax,1 
cmp eax, 1 
Overwrite: 
jnz SMC_ // esta instrucción quedará sustituida por JZ 


MessageBox ("El código del programa no se ha 
modificado",NULL,MB_OK) ; 
return; 
SMC: 
MessageBox ("El código del programa se ha modificado con 
éxito" ,NULL,MB_OK); 


Tras esta modificación, el mensaje mostrado será: “El código del programa se ha 
modificado con éxito”. 


Como puede comprobarse resulta verdaderamente simple. Consiste en un pequeño 
cambio en el modo de invocar la función “VirtualProtect” para aplicar derechos de 
escritura a una cierta área de memoria, en nuestro caso, al área donde se cargará el código 
ejecutable. 
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Ya se ha dicho anteriormente que éste es un ejemplo sencillísimo; sin embargo, 
demuestra maravillosamente el uso y potencial del SMC. Dependerá del programador, 
como siempre, el grado de perfección con el que se aplique esta técnica y el tiempo 
invertido en el diseño del código del programa. 


EDICIÓN DEL CÓDIGO DEL PROGRAMA EN TIEMPO DE 
EJECUCIÓN 


Entre los métodos mejores y más extendidos de protección de los programas frente 
al cracking se encuentran los que utilizan los principios básicos del SMC activo (por 
ejemplo, edición del código del programa en tiempo de ejecución). Sus posibilidades son 
realmente ilimitadas: cifrado del código del programa, modificación de las instrucciones 
individuales, destrucción intencionada de las instrucciones, y viceversa, inserción y 
desplazamiento de grandes bloques de datos, sobrescritura de funciones enteras, etc. En 
pocas palabras: los límites los marca la imaginación del usuario. 


Ya se ha puesto de manifiesto en este libro, y se volverá a insistir posteriormente, en 
las posibilidades de la edición del código de programa en el momento de su ejecución. En 
el anterior apartado de este capítulo sólo se quería apuntar lo sencillo que resulta. En el 
capítulo 7 se explicará la utilización del formato PE para cifrar y descifrar datos en tiempo 
de ejecución. 


CAPÍTULO 4 


PROTECCIÓN CONTRA FROGSICE 


Frogslce y ProcDump son dos de los programas imprescindibles para un cracker, 
Representa un antiantidepurador (o más bien un antiantiSoftICE) que puede identificar y 
engañar a la mayoría de los métodos más recientes para detectar un depurador. 


El programa, por explotar las librerías VxD, sólo funciona con sistemas operativos 
Windows 9x/Me. Esta limitación queda compensada por la gran variedad de funciones 
sumamente útiles que ofrece el programa: desde identificar las formas básicas de detección 
de depuradores hasta la supervisión de los vectores de interrupción. 


USO ELEMENTAL DE FROGSICE 


El corazón de Frogslce reside en una librería VxD del mismo nombre, que queda 
cargada en memoria y controlada por un programa denominado FPLoader. Al arrancar, el 
programa muestra un sencillo menú con diferentes opciones. 
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Figura 4-1. Entorno de trabajo de FrogsICE 


Al pulsar el botón “Enable FrogsICkE”, el programa carga la librería VxD 
anteriormente mencionada y quedan activos los servicios del programa. Para desactivarlos, 
púlsese “Disable FrogsICE”. A continuación se describen sus opciones. 


Opciones básicas 


BlueSereenOfDeath — uno de los métodos básicos de alertar al usuario mediante la 
“muy popular” pantalla azul con todos los detalles sobre la identificación realizada de un 
algoritmo para detectar depuradores u otra acción semejante. 


Hide SICE drivers — oculta los drivers de SoftICE (SICE, SIWDEBUG y 
SIWVID) de la lista DDB para evitar su detección —por ejemplo, con el método en el que 
se emplea la función API CreateFileAa—. 


Log to file — todo lo que suceda queda registrado en un fichero; la información se 
puede recuperar pulsando el botón “View Log”. 


Protect SICE files — protege los ficheros de SoftICE contra su eliminación o 
modificación. Algunos autores de algoritmos antidepurador ponen tanto empeño en su 
misión que tras detectar un depurador, lo borran. Con lo que corren el riesgo de ser 
demandados judicialmente por un cracker. 


Auto-scan on startup/exit — con cada arranque o parada de FrogsICE se realizan 
comprobaciones de áreas importantes de memoria (como IDT) buscando alguna 
modificación u otras características “sospechosas”. Si se desea realizar una comprobación 
al instante, púlsese el botón “Scan now”, 
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Hide FPLoader — oculta el fichero de arranque de FrogsICE. 


Beep! — se puede elegir como alerta un tono normal en vez de la pantalla 
BlueScreenOf Death. 


Opciones avanzadas 


Pop-up SoftICE — cuando una de las opciones se detecte, se mostrará un mensaje 
en una dirección específica indicando que SoftICE está listo. 


Hook DRx - esta opción ayuda a supervisar el acceso (en escritura o lectura) a los 
registros de depuración (Dr0 — Dr7). Ha de tenerse mucho cuidado puesto que puede 
provocar la caída del sistema. Se recomienda desactivarla o borrar todos los puntos de 
corte hardware definidos en SoftICE antes de activarla. Consúltese la documentación para 
asegurar su utilización correcta. 


IDT monitor/protector — garantiza la detección de cualquier intento de utilizar IDT 
(lista con los descriptores de las interrupciones). Herramienta sumamente útil para buscar 
protecciones mediante vectores de interrupción (sustituciones de vector, bifurcación al 
anillo 0, etc.). 


Hook int03h — en caso de que no esté activo SoftICE, esta opción puede detectar 
cualquier llamada a INT3. Muy útil, puesto que la interrupción se utiliza a menudo en 
algoritmos de protección de todo tipo. 


Adjust localtime to RTC — esta opción puede engañar a algunos algoritmos 
antidepurador basados en la medición del tiempo de proceso de algunas partes importantes 
del código de programa. 


ALGORITMOS COMUNES 


VxDCall de la función VMM_GetDDBList 


Algunos algoritmos dedicados a evitar la utilización de Frogslce utilizan la VxDCall 
de la función VMM_GetDDBList, en cuyo caso, si FrogsICE estuviera activo, causaría una 
excepción (la famosa pantalla azul). Al igual que se mencionó anteriormente con el uso de 
VxDCall, esta función debe invocarse desde el anillo 0. Así queda su uso limitado a 
Windows 9x/Me, lo que carece de importancia puesto que FrogsICE no se puede utilizar 
con otros sistemas. Según se observa en los ejemplos de las secciones anteriores, el empleo 
de este método no debe suponer ningún problema. Basta con mover el programa al anillo 0 
y ejecutar la función VMM_GetDDBList. Si FrogsICE estuviese activo, el programa 
generaría una excepción y, probablemente finalizaría. Si FrogsICE no estuviese activo, no 
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sucederá nada y el programa proseguirá su ejecución. Un ejemplo de dicho código puede 
ser el siguiente: 


_ asm 
( 
push edx 
sidt [esp-2] // lectura de IDT en la pila 
pop edx 
add edx, (3/*=INT 3*/*8)+4 // lectura del vector 


de interrupciones 
seleccionado, esto 
es, INT 3 

mov ebx, [edx] 

mov bx,word ptr [edx-4] // guardando la 
dirección de la 
anterior rutina de 
interrupciones 

lea edi,Ring0 

mov [edx-4] di 

ror edi,16 // definición de una 
rutina de 
interrupción INT3 


nueva 
mov [edx+2],di 
push ds 
push es 
INT 3 //-->anillo O 
pop es 
pop ds 
mov [edx-4] ,bx // recuperación de la 


rutina de 
interrupción INT3 


anterior 
ror ebx,16 
mov [edx+2] ,bx 
jmp Ok 
JR anillo OXRARARA Y 
Ringo: 
_ emit 0xCD // VMMCal1 


VMM_GetDDBList 
__emit 0x20 // 
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ORA-MA 
_ emit 0x3F e 
_ emit 1 e 
_ emit 1 el 
_ emit O HER 
iretd // si se ha llegado 
hasta aquí, FrogsICE 
no reside en memoria 
Ok: 
) 


Este ejemplo constituye una demostración ideal de lo falso del supuesto que afirma 
lo muy difícil que resulta utilizar la sustitución de vector para saltar al anillo O, Afirmación 
ya realizada varias veces anteriormente. Basta con activar la opción “IDT 
monitor/protector” de FrogsICE. Esta opción garantiza la detección de cualquier intento de 
utilizar IDT e informa al usuario de ello. Además, no se llegará a invocar la función 
VMM_GetDDBList, lo que volverá inútil al algoritmo. Si se desea saltar al anillo 0, 
deberá utilizarse otro método que no pueda ser detectado por FrogsICE. Parece que la 
mejor alternativa reside en SEH. En el ejemplo siguiente se provoca la excepción 
C0000005h -STATUS_ACCESS VIOLATION para dar paso a nuestro manejador: 


_ asm 
( 
mov ax, ds 
test al,4 
je Not_Win9x 
Win9x: 


push offset MyHandler 


push dword ptr fs: [0] 


mov dword ptr fs: [0], esp 
pushtfd 
mov eax, esp 
xor ebx,ebx 
mov ecx, [ebx] 


[RREAAAFARÍNGO A AAA AAA 


push edx //GS 
push edx //FS 


// ¿sistema operativo? 

// bifurcación = el 
sistema operativo no 
es Windows 9x/Me 


// guardando la 
dirección de nuestro 
manejador 

// guardando la 
dirección del 
manejador anterior 

// instalación 


// EBX = 0 
//--> anillo 0 
(STATUS ACCESS VIOLATION) 
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push edx //ES 

push edx //DS 

push edx //SS 

push eax //ESP 

push dword ptr [eax] 
push ecx 

push offset Ring3 


_ emit 0xCD 


_ emit 0x20 


Ring3: 
poptd 
pop dword ptr fs: [0] 


add esp, 4 
jmp Ok 


pPpoooorrkMyHandler** ex. / 
// SEH handler for jump to Ring0 


MyHandler: 
mov edx, [esp+0Ch] 
mov ecx, [esp+4] 
mov ecx, [ecx] 


cmp ecx,0C0000005h 


jne Error 


// EFLAGS 

// Cs 

// EIP = dirección 
para volver 
al anillo 3 


// “VMMCall 
VMM_GetDDBLi 
st 

Le 

1! 

Zi 

Ze 

// 

//--> anillo 3 

// si se ha llegado 

hasta aquí, FrogsICE 
no reside en memoria 


// recuperación del 
manejador 
anterior 

// ajuste de pila 


// CONTEXT 

£/ EXCEPTION_RECORD 

// ECX = valor de la 
excepción recién 
ocurrida 

// ¿excepción 
STATUS ACCESS VIOLATION 
(C0000005h) ? 

// bifurcación = 
excepción que no se 
procesará por este 
manejador 
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add dword ptr [edx+0B8h],2 // recuperación de la 
excepción saltando 
la instrucción 


, incorrecta 
movzx ecx,word ptr [edx+0BCh] 
mov [edx+0ACh] ,ecx 
mov dword ptr [edx+0BCh],28h 
movzx ecx,word ptr [edx+0C8h] 
mov [edx+0A8h] ,ecx 
mov dword ptr [edx+0C8h],30h 
or dword ptr [edx+0C0h],200h 
sub eax,eax / / ExcepticnContinuerxecution 
ret //--> anillo 0 
Error: 
sub eax,eax 
inc eax / /ExceptionContinueSearch 
ret 
) 
Not_Win9x: 


MessageBox ("Este método sólo funciona con Windows 
9x/Me” ,NULL,MB_OK); 
return; 
Ok: 
MessageBox (“"FrogsICE no detectado” ,NULL,MB_O0K) ; 


Uso de la función CreateFileA 


Algunas de las versiones antiguas de FrogsICE podían detectarse, al igual que 
SoftICE, identificando sus drivers mediante la función CreateFileaA (o CreateFileW). 
En la práctica resulta el método idéntico al empleado para la detección de SoftICE, 
únicamente varía el nombre del driver. 


HANDLE File = CreateFile("MIW.ANFROGSICE”,GENERIC_READ | 
GENERIC WRITE, FILE _SHARE_READ | 
FILE SHARE WRITE, NULL,OPEN_EXISTING, 
FILE ATTRIBUTE_NORMAL, NULL); 


if(File != INVALID_HANDLE_VALUE) // ¿driver de FrogsICE 
detectado? 
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CloseHandle (File); 

MessageBox ("FrogsICE detectado” ,NULL,MB_OK); 
) 
else 


MessageBox ("FrogsICE no detectado” ,NULL,MB_0K) ; 


Sin embargo, este método no funciona con las versiones más recientes de FrogsICE. 
FrogsICE informa de todo, y por razones de seguridad y para evitar una excepción 
potencial con colapso del sistema incluido, elude cualquier intento de detección de este 
tipo. 


CAPÍTULO 5 


PROTECCIÓN CONTRA PROCDUMP 


ProcDump es un descodificador-descompresor PE universal, además realiza 
volcados de memoria, editor y regenerador de ficheros PE. Constituye un complejo 
programa que reúne todo lo necesario para descodificar y descomprimir ficheros PB, 


Este programa, gracias a su increíble flexibilidad, y a pesar de que su desarrollo se 
paralizó hace casi dos años, tiene la posibilidad de ampliar constantemente sus 
características y propiedades. Con cierta regularidad aparecen plug-ins en Internet para su 
utilización en el mercado de protección de software, en expansión constante. 


USO ELEMENTAL DE PROCDUMP 


La interfaz del programa, nada más arrancar, suele provocar una sonrisa de 
complacencia en el usuario. 
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Wsystemroot|system32jsmss.exe 

2 Acwinntisystem32|winlogon,exe 
cifwinntisyster32|services,exe 
ciJwinntisystem3Zllsass.exe 
c:|winntisystem32Asvchost,exe 
cifwinntlsystem321spoolsv.exe 


1 csiwinntisvstem32Asvchost,exe 


Figura 5-1. Menú básico de ProcDump 


Su utilización resulta muy sencilla. 

Al pulsar el botón “Umpack”, el programa muestra una lista de todos los 
codificadores y compresores PE que ProcDump puede tratar automáticamente. Se puede 
elegir entre las posibilidades siguientes (versión 1.6.2): 

e  Aspack<108 

e  Aspackl108 

e  Aspack108.2 

e  Aspack108.3 

e  Aspack108.4 

e  Aspack2000 

e  CodeSafe 3.X 
+  Hasiuk/NeoLite 
o Manolo 


e  Neolite2 


e PCGUARD v2.10 


ORA-MA 
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PCShrink 
PCShrink II 
PE-Compact 
PE-Pack 
PESHiELD 
Petite 2.0 
Petite<1.3 
PKLIiTE 
Sentinel 
Shrinker 3.2 
Shrinker 3.x 
SoftSentry 
Standard 


UPX 


Choose Unpacker 


Hasiuk/NeoLite 
Manolo 
Neolite2 


Figura 5-2. Diferentes alternativas de ProcDump 
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e  Vbox Dialog 
e  VboxStd 

e  VGCrypt0.75 
e Wwpack32 


El procedimiento que rige el uso de los anteriores compresores PE se describe 
claramente con el lenguaje de programación aplicable al fichero script.ini. No constituye, 
por tanto, ningún problema examinar los métodos individuales de protección y, más 
importante aún, modificarlos y añadir otros codificadores completamente nuevos que 
ProcDump pueda utilizar, Todo queda escrito y explicado en el fichero script.txt. 


A continuación, se elige un fichero y un método de protección, ProcDump realizará 
el resto. Si todo va bien, sólo quedará seleccionar el nombre del fichero resultante. 


Éste, en ocasiones, exige reconstruirse de una forma concreta. Para ello utilícese el 
botón “Rebuild PE”. En la ventana “Options” se pueden elegir diferentes posibilidades 
para reconstruir el fichero. 


ProcDump32 Options 


-Rebuilder Options 
Structure: 

[Y Recompute Object Size 
¡(Y Oplimiza PE structure 
| 1 Check Header Sections 
| TC Rebuld Header 


[ doors 


1 
T Force ta made. T” Merge code into an unique section ¡Save 


Figura 5-3. Distintas posibilidades de configuración en ProcDump 


Generalmente se suele reconstruir la tabla de importaciones (si fuera posible), 
modificar la cabecera del fichero PE, y otras acciones similares. Estas operaciones varían 
según el método protección. 


El botón “PE Editor” muestra las distintas posibilidades del editor de ficheros PE. 
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PE Structure Editor 


- Header Infos —— 
Entry Point: ¡DOT5A0A0 Sections 
N | 


Size ofimage : [oo15FoDO | a 
* Only to eader 
Image Base: — [00400000 | 


Figura 5-4. Editor de ficheros PE de ProcDump 


Resulta, sin embargo, preferible emplear un editor PE especializado como el 
incluido en el CD adjunto. 


El botón “Bhrama Server” activa la aplicación servidor encargada de suprimir 
enteramente otro tipo de protecciones, como Securom, VBox y Petite. Cada una de ellas 
exige su cliente. 


ProcDump32 - Dumper Server 


Bhrama server 0.3 started 


Waiting Client command ... 


TT User Conf. IV AutoFix PE 


Figura 5-5. Brahma Server a la espera de respuesta del cliente 


En el capítulo 7 se examinarán con más detalle éstas y otras opciones aplicables a 
los ficheros PE. En el capítulo 9, dedicado a ejemplos de cracking, se describirán las 
restantes funciones de ProcDump, como el volcado de memoria. 


DEFINICIÓN Y OBJETIVO DEL VOLCADO DE MEMORIA 


La técnica de volcar el contenido de la memoria al disco se utiliza principalmente 
cuando un programa descifra (o modifica de alguna manera) ciertos datos en tiempo de 
ejecución porque la lógica del programa exija esos datos descifrados. A un cracker le 
bastaría esperar a que los datos se descifren para guardarlos y examinarlos posteriormente. 
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Los volcados de memoria constituyen el punto de partida para eliminar las 
protecciones basadas en compresores-codificadores PE. 


ALGORITMOS COMUNES 


Una de las acciones elementales que cualquier algoritmo de protección debe incluir 
consiste en evitar un volcado realizado por ProcDump. Más aún en el caso de los 
compresores-codificadores PE, donde el volcado de memoria constituye un punto esencial 
en la supresión de protecciones. Resulta evidente que con ProcDump se puede 
descomprimir la inmensa mayoría de codificadores y compresores PE de hoy en día, lo 
que revela el hecho de que estos algoritmos apenas ya se utilizan para proteger software. 


Resulta pueril pensar que por utilizar un algoritmo que imposibilite el volcado con 
ProcDump, un programa va a quedar protegido contra el volcado de memoria o contra la 
supresión del compresor-codificador PE. Y más infantil resulta todavía cuando un cracker 
puede volcar la memoria y descifrar manualmente un fichero mediante uno de los muchos 
otros programas equivalentes disponibles en Internet, o bien utilizando un descompresor 
distinto (y, por supuesto, suprimiendo dicho algoritmo). 


Por otra parte, en cierta medida este algoritmo protege de forma general contra la 
supresión de los mecanismos de protección y contra el volcado realizado por uno de los 
programas más extendidos con tal propósito: ProcDump. Como mínimo, el programa 
estará defendido frente a todos los principiantes, que se verán obligados a buscar una 
alternativa diferente. 


Se puede evitar el volcado realizado por ProcDump modificando la cabecera PE del 
fichero almacenado en memoria y utilizado internamente por el sistema. Si el tamaño de un 
proceso dado cambia a 1, ProcDump colapsará al intentar volcar el proceso. Dicho tamaño 
puede también aumentarse, disminuirse o modificarse de alguna forma, pero en la mayoría 
de los casos ProcDump logrará, al menos parcialmente, volcar tal proceso (pruebe el lector 
y lo comprobará). 


El proceso para modificar el tamaño del fichero en su cabecera PE con Windows 
NT/2000/XP difiere al de Windows 9x/Me. Por tanto, resulta imprescindible comprobar la 
plataforma al principio del algoritmo. 


_ asm 
( 

push fs: [30h] 

pop eax 

test eax, eax // ¿sistema operativo ? 

js Win9x // bifurcación = el sistema 


operativo es Windows 9x/Me 
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Not_Win9x: 
mov eax, [eax+0Ch] 
mov eax, [eax+0Ch] 
mov dword ptr [eax+20h],1 // ajuste de tamaño 


jmp End 
Win9x: 

GetModuleHandle (NULL) ; // con Windows 9x/Me 
esta función copia 
en EDX los datos 
solicitados 

asm 


test edx,edx 
jns End // ¿se invocó la función con éxito? 
cmp dword ptr [edx+8],-1 
jne End // segunda comprobación 
mov edx, [edx+4] 
mov dword ptr [edx+50h],1 // ajuste de tamaño 
) 
End: 
MessageBox ("Inténtese ahora volcar este proceso con 
ProcDump” ,NULL,MB_0K) ; 


CAPÍTULO 6 


EDICIÓN DEL CÓDIGO DEL PROGRAMA 


Probablemente sea superfluo destacar la importancia que tiene la edición del código 
del programa en el cracking. En sentido estricto, se podría afirmar que la modificación del 
código original del programa constituye una actividad ilegal en sí misma. Al menos, ésa 
suele ser la opinión de los profanos. 


En muchas ocasiones, el cracker puede alcanzar su objetivo sin editar el código del 
programa (obteniendo el número de serie correcto O la contraseña, reconstruyendo el 
fichero clave, etc.). En otras, no queda más remedio. 


Generalmente el término “edición” se relaciona con un editor: es decir, un programa 
que facilita la edición. En este contexto, resulta preferible emplear un editor que sea capaz 
de trabajar con el código máquina del programa de manera legible. La edición del código 
máquina en formato binario puede llegar a ser inmanejable. Razón por la que se utiliza el 
formato hexadecimal. De donde procede el nombre del propio editor: editor hexadecimal. 
Algunos de ellos son capaces inclusive de mostrar directamente el código máquina en 
ensamblador, al igual que lo hace un desensamblador (seguidamente se examinará uno de 
estos editores). 


A menudo se emplea el término “parchear” para referirse a la edición del código del 
programa, y por extensión, a los cracks que modifican el código de programa: parches. 
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MÉTODOS PARA EDITAR EL CÓDIGO DEL PROGRAMA 


La edición del código de programa mediante un editor hexadecimal no constituye en 
absoluto el único medio para modificar el código del programa. Además de editar 
directamente un fichero dado en el disco duro mediante un editor hexadecimal, también se 
puede editar el fichero una vez que se cargue en memoria. A diferencia del editor 
hexadecimal, donde las modificaciones se realizan directamente en un fichero almacenado 
en el disco duro, con el segundo método es la ubicación (o ubicaciones) de memoria donde 
resida el fichero lo que se modifica (normalmente mediante la función API 
WriteProcessMemory) y no el fichero propiamente dicho. 


En las siguientes secciones de este capítulo se muestran las principales diferencias 
entre estas dos técnicas y la forma de defenderse ante ellas. 


USO ELEMENTAL DE HIEW 


Se puede elegir entre la amplia variedad de editores disponibles aquel que más 
convenga. Hiew constituye uno de los mejores actualmente. 


Su apariencia, típica de los sistemas DOS, no debiera desanimar al posible usuario. 
Sus propiedades superan claramente a las de la mayoría de los editores hexadecimales, al 
empezar a utilizarlo enseguida se aprecia su facilidad de uso y rapidez. 


Ba 
an 


B0 Ya ga 
al 


Figura 6-1. Aspecto de Hiew, típico de DOS 


Pulsando la tecla F4 se ofrecerán diferentes modos de presentación. Hiew muestra 
el fichero en edición de tres modos diferentes: en modo texto (“Text”), en formato 
hexadecimal con texto (“Hex”), o directamente las instrucciones en ensamblador 
(“Decode”). Se puede saltar de un modo representación a otro pulsando la tecla intro. 
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Desde el modo hexadecimal o ensamblador, al pulsar la tecla FS el usuario podrá 
desplazarse a cualquier ubicación del fichero indicando su desplazamiento real (“raw 
offset”, en inglés). La dirección debe introducirse en formato hexadecimal. 


La tecla F3, desde el modo hexadecimal o ensamblador, sirve para editar el fichero. 
Desde este último modo se puede introducir directamente una instrucción en ensamblador 
pulsando la tecla de F2. Muy útil cuando no se sabe la expresión numérica de las 
instrucciones individuales (en formato hexadecimal en nuestro caso). El resultado de la 
petición se guarda pulsando la tecla F9, 


Otra característica muy útil consiste en la capacidad de búsqueda tanto en formato 
ASCII como en código hexadecimal. La tecla F7 muestra el cuadro de diálogo pertinente. 


Hasta aquí una breve descripción de las características básicas del programa Hiew. 
Seguidamente se describirán otras características muy atractivas. 


Edición de un programa para detectar SoftICE 


Se examinará ahora cómo funciona Hiew en la práctica. Se tomará como ejemplo el 
código del programa empleado en el capítulo 2. El código que utiliza la función API 
CreateFileA quedará modificado para que detecte el programa SoftICE y que, 
independientemente de resultado de la detección, genere un mensaje indicando que no se 
detectó a SoftICE. A continuación se presenta el código de ejemplo: 


HANDLE File; 
BYTE Win9x = 0; 
asm 


( 


push £s: [30h] 

pop eax 

test eax,eax // ¿sistema operativo? 

jns Not_Win9x // bifurcación = el sistema 
operativo es Windows 9x/Me 

mov byte ptr Win9x,1 


Not_Win9x: 


) 


if (Win9x) 


File = CreateFile( "AMWM.ASICE”,GENERIC_READ 
GENERIC WRITE, FILE SHARE_READ 
FILE SHARE WRITE, NULL,OPEN_EXISTING, 
FILE ATTRIBUTE_NORMAL, NULL); 
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else 
( 
File = CreateFile(“AMWM.MWNTICE”,GENERIC_READ | 
GENERIC WRITE, FILE SHARE READ | 
FILE SHARE WRITE,NULL,OPEN_EXISTING, 
FILE_ATTRIBUTE_NORMAL,NULL); 
) 


if( File l= INVALID HANDLE VALUE ) // ¿driver de 
SoftICE detectado? 


( 

CloseHandle (File); 

MessageBox ("SoftICE detectado” ,NULL,MB_OK); 
) 
else 


MessageBox (“"SoftICE no detectado” NULL, MB_OK) ; 


En un programa de estas dimensiones resulta sencillo detectar el algoritmo mediante 
un editor hexadecimal. Ahora bien, puesto que no se suele utilizar un editor hexadecimal 
para recorrer un fichero tan pequeño en búsqueda del algoritmo, seguidamente se 
describirá cómo localizar el objetivo deseado con el desensamblador para luego utilizar la 
dirección obtenida con Hiew. 


Ábrase en primer lugar el fichero con el desensamblador W32Dasm. A 
continuación ha de diseñarse una estrategia para localizar el algoritmo de detección de 
SoftICE. Esta ubicación se puede hallar bien aplicando el código dado donde figura las 
sentencias “SoftICE detectado” o “SoftICE no detectado”, o bien utilizando las funciones 
importadas —función API CreateFileA—, Selecciónese la opción preferida (doble 
pulsación en la función/mensaje seleccionado). El código siguiente muestra el programa en 
ensamblador: 


Possible StringData Ref from Data Obj ->"Al.ASICE” 


:00401364 6850304000 push 00403050 
:00401369 EBO5 jmp 00401370 


* Referenced by a (U)nconditional or (C)onditional Jump 
* at Address: 00401362 (C) 


* Possible StringData Ref from Data Obj ->"AX.ÁNTICE" 
:0040136B 6844304000 push 00403044 


* Referenced by a (U)nconditional or (C)onditional Jump 
* at Address: 00401369 (U) 
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* Reference To: KERNEL32.CreateFileA, Ord:0034h 


:00401370 FF1500204000 Call dword ptr [00402000] 
:00401376 83F8FF cmp eax, FFFFFFFF <-- if (File != 
<-- INVALID HANDLE VALUE) 
:00401379 741C je 00401397 <-- bifurcación = SoftICE no 
<-- detectado 
:0040137B 50 push eax 


* Reference To: KERNEL32.CloseHandle, Ord:001Bh 


:00401370 FF1508204000 Call dword ptr [00402008] 
:00401382 6A00 push 00000000 
:00401384 6A00 push 00000000 


* Possible StringData de Data Obj ->"SOoftICE detectado” 


:00401386 6834304000 push 00403034 
:0040138B 8BCE mov ecx,esi 


* Reference To: MFC42.Ordinal:1080, Ord:1080h 


:0040138D E81E020000 Call 004015B0 
:00401392 5E pop esi 

:00401393 8BES5 mov esp,ebp 
:00401395 5D pop ebp 

:00401396 C3 ret 


* Referenced by a (U)jnconditional or (C)onditional Jump 
* at Address:00401379(C) 


:00401397 6A00 push 00000000 
:00401399 6A00 push 00000000 


* Possible StringData de Data Obj ->"SoftICE not found” 


:0040139B 6820304000 push 00403020 
:004013A0 8BCE mov ecx, esi 


* Reference To: MFC42.Ordinal:1080, Ord:1080h 


:004013A2 E809020000 Call 004015B0 
:004013A7 5E pop esi 

:004013A8 8BE5 mov esp, ebp 
:004013AA 5D pop ebp 

:004013AB C3 ret 
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El código resulta muy simple. Si se produce una bifurcación en la dirección 
00401379, se mostrará el mensaje "SoftICE no detectado”. Por tanto, si se modifica la 
bifurcación para que en vez de condicional sea incondicional (se produce siempre), el 
mensaje se mostrará siempre. (Por supuesto ésta no es la única solución posible.) 


Defínase el indicador de la instrucción de bifurcación condicional JE a la dirección 
00401379 y obsérvese la barra de estado de W32Dasm. Se apreciará el valor de 
desplazamiento 00001379h, que define su posición real en el fichero. De esta manera se 
dispone de toda la información necesaria para editar el fichero. 


Ábrase Hiew con el programa que se está estudiando. Pulse dos veces la tecla intro 
para operar en modo ensamblador. Seguidamente FS y el valor de desplazamiento (1379h, 
sin la "h" por supuesto). La herramienta se situará en la ubicación de la instrucción de 
bifurcación condicional (JE). Púlsese F3 para editar la edición y modificar el valor inicial 
de la instrucción de bifurcación 74h a EBh. De este modo, la instrucción de bifurcación 
condicional se convierte en incondicional (JMP). Sólo resta pulsar F9 para guardar las 
modificaciones en el fichero. Ya está. El programa siempre indicará que SoftICE no se ha 
detectado, independientemente del resultado de la detección. 


Con este ejemplo se pretendía ilustrar no sólo cómo utilizar el editor hexadecimal 
Hiew, sino también lo fácil que resulta someter una aplicación no protegida con un 
desensamblador y un editor hexadecimal. En la siguiente sección se describirá cómo 
protegerse frente a esta técnica. 


ALGORITMOS COMUNES 


Comprobación de la integridad de los datos 


Probablemente sea la comprobación de la integridad de los datos la manera más 
conocida de proteger el código de un programa frente a su edición. Al igual que se 
comprueba la integridad de los paquetes de datos enviados a través de Internet, una 
aplicación también puede comprobar su propia integridad. 


Como con todo lo demás, el éxito de este tipo de protección dependerá de su 
correcta aplicación y del modo en que el algoritmo de protección reaccione cuando detecte 
intentos de vulnerarlo, 


COMPROBACIÓN DE LA INTEGRIDAD DE LOS DATOS DE UN 
FICHERO 


Los primeros algoritmos para comprobar la integridad de los datos empleaban las 
funciones API CreateFileA y ReadFile, con ellas se cargaba en memoria el contenido 
de un fichero para luego efectuar la comprobación mediante el algoritmo correspondiente. 
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El código podría asemejarse al siguiente: 


DWORD NOBR; 
HANDLE File = 
CreateFile("file name” ¡GENERIC_READ, FILE _SHARE_READ, 
NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL) ; 
// obtención del manejador de fichero 
BYTE *pMem = new BYTE [GetFileSize(File,NULLD)]; 
// asignar memoria 
ReadFile (File,pMem, GetFileSize (File,NULL) , £NOBR, NULL) ; 
// cargar fichero en memoria 
DWORD CheckSum = 
CalculateCheckSum (pMem, checked_data_area...etc.); 
if (CheckSum == CorrectCheckSum) 


// todo correcto... 


) 


CloseHandle (File); 
delete pMem; 


Se puede encontrar un ejemplo práctico de este algoritmo en el CD incluido en este 
libro y también en algunos programas del capítulo 9, 


También se suele aplicar la función MapFileAndCheckSum con el mismo objetivo. 
En este caso, desgraciadamente, resulta imposible definir el área de datos procesada y ha 
de efectuarse necesariamente la comprobación de integridad con el fichero entero. Más 
aún, dicha función sólo se puede aplicar a ficheros compatibles con el formato PE (véase 
el siguiente capítulo). 


Esta función no resulta muy apropiada si el programa ha de comprobar su propia 
integridad ya que siempre será obligatorio guardar el valor correcto de la comprobación en 
una ubicación que quede fuera de su cálculo, lo que no resulta tan fácil. A diferencia del 
algoritmo anterior, no es posible controlar el área de datos contra los que se efectúa la 
comprobación. El área donde se guarde el valor correcto de la comprobación podrá ser 
bien la variable CheckSum, en la estructura IMAGE OPTIONAL HEADER32 de la cabecera 
del fichero con formato PE, donde "nadie" se lo esperaría, o en una ubicación fuera de 
fichero, lo que podría resultar demasiado lento y no suficientemente seguro. 


Siempre que se utilice esta función resultará lógicamente imposible guardar 
directamente en el código del programa el valor correcto de la comprobación —el 
programa deberá contener el valor de la comprobación calculada, que sólo se podrá hallar 
después de que se ejecute el algoritmo que la calcula—, puesto que este algoritmo también 
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abarca la parte del código que contiene la verificación del valor calculado de la 
comprobación. 


La función MapFileAndCheckSum constituye una solución excelente para realizar 
comprobaciones de integridad de otros ficheros tipo PE, como librerías DDL, con rapidez 
y comodidad. Su principal ventaja radica en que el resultado de la función 
MapFileAndCheckSum es el valor calculado de la comprobación. Lo que evita codificar 
un algoritmo diferente para calcularlo, a diferencia del ejemplo anterior. 


El código resulta muy sencillo: 


DWORD PECheckSum, CalculatedCheckSum; 
MapFileAndCheckSum (“file name”, £PECheckSum, ¿CalculatedChec 
kSum) ; 


La función obtiene dos valores de comprobación. El primero, guardado en la 
variable PEChecksum, recoge los contenidos de la variable anteriormente mencionada 
CheckSum de la estructura IMAGE OPTIONAL HEADER32 de la cabecera del fichero PE. 
Según se mencionó anteriormente, se puede utilizar esta variable para verificar la segunda 
comprobación, guardada en la variable CalculatedcheckSum. Esta segunda variable 
representa el valor correcto de la comprobación efectuada sobre un fichero dado. En el CD 
incluido en este libro se puede encontrar un ejemplo práctico de este algoritmo. 


El primer punto débil, obvio por otra parte, de estos algoritmos radica en el uso de 
funciones muy conocidas. Inmediatamente quedó de manifiesto que éste no era el único 
problema con este tipo de protecciones. Su principal deficiencia consiste en que la 
comprobación se realiza sobre el contenido del fichero en disco y no sobre el contenido en 
memoria, donde el programa queda cargado al ejecutarse. Los crackers, en vez de editar el 
fichero directamente desde el disco con un editor hexadecimal, lo editan desde la memoria 
con el programa ya cargado, con lo que la protección quedará anulada. Los programas 
destinados a esta tarea se denominan cargadores. Con frecuencia ejecutan el programa con 
la función API CreateProcess para luego aplicar los cambios en memoria mediante la 
función WriteProcessMemory. 


Estos métodos para comprobar la integridad de los datos apenas se utilizan ya, o 
mejor dicho, no deberían utilizarse. Como la excepción confirma la regla, no sería extraño 
encontrar algunos sistemas de protección modernos que apliquen este método. 
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RAZOR 1911 Loader 


Autoloading Brood Wars virtual crack patch... 


AO emm. A 


Figura 6-2. Cargador StarCraft 


Los cargadores también se suelen utilizar para editar programas protegidos con 
compresores-codificadores PE. En este caso, el cargador espera hasta que el fichero se 
descifre y los datos solicitados se carguen en el área de memoria que contiene el programa 
descifrado. No se profundizará ahora en este tema puesto que el capítulo siguiente está 
dedicado por completo al formato PE. 


Además de un generador de cargadores, en el capítulo 8 se describirá cómo 
programar cargadores. A continuación se muestra un código ejemplo de cargador: 


DWORD OverwriteAddress,NOBW; 

BYTE OverwriteValue; 

PROCESS INFORMATION ProcessInfo; 

STARTUPINFO StartInfo; 

Startinfo.cb = sizeof (Startin£fo); 

Startinfo.lpReserved = NULL; 

StartInfo.lpDesktop = NULL; 

StartInfo.lpTitle = NULL; 

Sstartinfo.dwFlags = 0; 

StartInfo.cbReserved2 = 0; 

StartInfo.lpReserved2 = NULL; 

Overwritedddress = 0x004014B6; // dirección de memoria 

// donde se aplican las 
//modificaciones, por 

//ejemplo 004014B6 se 
// escribe: 

OverwriteValue = 0x74 //en una ubicación dada de 
//memoria, por ejemplo 74h 
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CreateProcess 
(“file _name”,NULL,NULL,NULL, false, CREATE_SUSPENDED, 
NULL,NULL, €StartInfo, £ProcessInfo); // crea el proceso de 
// la aplicación dada 
//con el parámetro 
//CREATE_SUSPENDED, 
// con lo que el 
// programa se cargará 
//en memoria pero no se 
//ejecutará 
WriteProcessMemory 
(ProcessInfo.hProcess, (LPVOID) OverwriteAddress, 
£OverwriteValue,sizeof (OverwriteValue),£NOBW) ; 
// aplica los cambios en memoria 
ResumeThread (ProcessInfo.hThread); 
// ejecuta la aplicación 


COMPROBACIÓN DE LA INTEGRIDAD DE LOS DATOS EN 
MEMORIA 


Resulta preferible efectuar la comprobación de integridad directamente en memoria 
una vez que el programa se haya cargado en su arranque. Además de que, a diferencia del 
método anterior, esta técnica no exija cargar el fichero (o partes de él) repetidas veces en 
memoria (donde ya reside), sortea los principales problemas de seguridad (uso de 
funciones API bien conocidas, etc.) que tal método comportaba. Resulta también mucho 
más simple y por añadidura, permite detectar cualquier punto de corte bxp definido. Estos 
puntos de corte sobrescriben los datos al valor CCh, lo que provoca un resultado incorrecto 
en la comprobación de integridad. 


Resulta importante, sin embargo, destacar la siguiente observación. Al aplicar los 
antiguos mecanismos para comprobar la integridad de los datos en disco, no tiene ninguna 
importancia cuándo y cuántas veces se realice la comprobación, puesto que el cargador 
modifica el programa en memoria. Al efectuar la comprobación de integridad en memoria, 
por contra, el programador debe recordar cuándo y cuántas veces se calcula. Si sólo se 
realizase una vez en el arranque, la protección será muy vulnerable frente a los cargadores. 
Al igual que sucede con los compresores-codificadores tipo PE, al cargador le bastará con 
esperar a que el fichero quede descomprimido para realizar sus modificaciones, en este 
caso habrá de esperar a que finalice la comprobación de integridad para modificar los 
contenidos en memoria. Se hace necesario, por tanto, efectuar comprobaciones de 
integridad constante y repetidamente, si fuera posible además, enteramente al azar. Bajo 
ninguna circunstancia, el programador debiera definir una sola función a la que se invoque 
repetidas veces, puesto que la mayoría de las ocasiones bastaría con anular esta sola 
función. Al igual que con muchos otros tipos de protección (comprobar la validez de la 
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información del registro legal del programa, por ejemplo), debe huirse de un componente 
central de protección y crear partes completamente independientes que contengan todo el 
código necesario. 


Antes de describir la comprobación de integridad en memoria, se describirá el tipo 
de algoritmo empleado en su cálculo. 


Probablemente el algoritmo más extendido sea CRC, código de redundancia cíclica 
(en inglés, “Cyclic Redundancy Check”). Se aplica a un amplio abanico de aplicaciones 
actuales tanto en su formato CRC-32 (calcula un valor de 32 bits al realizar la 
comprobación) como en el de CRC-16 (calcula un valor de 16 bits). 


Al emplear el algoritmo CRC-32, debe generarse primero la tabla de constantes que 
utilizará el algoritmo en sus cálculos. El código correspondiente se asemejará al siguiente: 


ULONG ulPolynomial = 0x04c11db7;// polinomio oficial 
// designado para 
// generar la tabla de 
// valores del 
// algoritmo CRC-32 
for(int 1 = 0; i <= OXxFF; i++) 
[ //generación de la tabla de valores 
CRC32_Tableli] = Reflect (1,8) << 24; 
for (int j =0; ] + 8; J++) 
CRC32_Table [1] = (CRC32_Table[i] «e 1) 
((CRC32 Table[i] £(1 << 31) ? ulPolynomial : 0); 
CRC32 Table[il = Reflect (CRC32_Table[i],32); 


) 


[kk kkexx* se puede realizar el cálculo CRC-32 con la 
función siguiente pero sin cumplir con el estándar 
HARRY 

ULONG ...::Reflect (ULONG ref,char ch) 


( 


A 


ULONG value(0); 
for(int i = 1; i< (ch +1); 14+) 


if (ref £ 1) 
value |= 1 << (ch - 1)); 
ref s»= 1; 


) 


return value; 


) 
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No obstante, no es estrictamente obligatorio emplear estas funciones: puede 
utilizarse una tabla de constantes ya generada. Dichas tablas se podrán incluir en la sección 
de referencias junto con el algoritmo CRC-32 en un programa ensamblador. 


La función que realice las comprobaciones de integridad se asemejará a lo siguiente: 


PRORRRORO RR RR RORO ROO ROO ROO RAR AAA 


/**Input: CheckedDataAddress de / 
per DataLength **/ 
ex * */ 
/* * *k/ 


JPRRRORRO ORO ROO ROO ROO ROO ROO OOOO ARA AAA 


JARA RA ORO- 324 AAA 
DWORD Crc = OxXFFFFFFFF; 
LPBYTE Buffer = (LPBYTE) CheckedDataAddress; 


while (DataLength--) 


( 
) 


Crc = Crc * OxXFFFFFFFF; // Crc = valor de 32 bits 
//resultante de la comprobación 


Crc =(Cre >> 8) * CRC32 Table[(Crc £ OXxFF) * *Buffer++]; 


Este tipo de algoritmo de protección resulta innecesariamente complejo. Dependerá 
principalmente de la eficacia con la que se realice y oculte la comprobación de integridad. 
A un cracker no le interesará en absoluto lo maravilloso y complejo que sea un algoritmo 
de este tipo. 


En la mayoría de los casos bastará con un algoritmo parecido al siguiente: 
asm 


mov ecx,data_length 
mov edi,start_trom 


xor eax,eax // redefinición de los 
// registros necesarios 

xor ebx,ebx 

xor esi,esi 


Looop: 
mov al,byte ptr [edi] // carga de datos 
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mul esi // multiplicación 
add ebx,eax // resultado a EBX 
inc edi // desplazándose al siguiente byte 
inc esi // aumenta ESI 
loop Looop // bucle en la comprobación, 
// contador = data_length 


//--> EBX = comprobación 


Puede servir este algoritmo de guía para crear uno propio. 


En el ejemplo siguiente se muestra cómo realizar con sencillez la comprobación de 
integridad directamente en memoria. En él, se calcula la comprobación con áreas 
importantes del código de programa mediante el algoritmo anterior: 


inc 


eax, offset EndImpArea 
eax, offset ImportantArea // EAX = longitud 


ecx, eax 


edi,offset ImportantArea 


eax, eax 


ebx, ebx 
esi,esi 


al,byte 
esi 
ebx, eax 
edi 


esi 


loop Looop 
//--> EBX = comprobación 
// no es preciso guardar el valor EBX - el código 
siguiente no lo modifica // 


ptr [edil 


// de los datos 
// comprobados 


// dirección en 
// la que comenzará 

// la comprobación 
// redefinición de los 
// registros necesarios 


// carga de datos 
// multiplicación 
// resultados a EBX 
// desplazándose al 
// siguiente byte 
// aumenta ESI 
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/¡****x*x** La única función del código siguiente consiste en 
permitir generar la comprobación. Por tanto ni siquiera 
resulta necesario ejecutarlo. Sustitúyanse estos datos con 
los reales que el usuario quiera comprobar.***x*x*x*x*/ 
ImportantArea: 

nop // código 

// absolutamente inútil 

nop 

inc ebx 

dec ebx 

push eax 

pop eax 

nop 

nop 


EndImpArea: 
cmp ebx, 1463Fh // comparación entre el valor 
// correcto de la comprobación y el 
//calculado 
je Ok 
) 
MessageBox (“El código del programa ha quedado 
modificado” ,NULL,MB_OK); 
return; 


Ok: 


MessageBox (“El código del programa no ha quedado 
modificado”,NULL,MB_O0K) ; 


El algoritmo identificará todo intento de modificar el área de datos comprobada o de 
definir un punto de corte bpx. Es más, este algoritmo resulta bastante difícil de detectar 
por no utilizar ninguna función API. (La función MessageBoxA tan sólo se utiliza aquí 
como ejemplo, nunca debería emplearse en la protección.) Puesto que los crackers suelen 
utilizar puntos de corte bpm y bpr para encontrar estos tipos de protección, no debe 
olvidarse detectar su presencia. 


En el CD adjunto se pueden encontrar algunos ejemplos donde se aplican 
comprobaciones de integridad con ficheros y en memoria empleando los algoritmos 
anteriormente mencionados. 
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Para quien no entienda cómo obtener el valor de comprobación correcto, bastará 
con aplicar a un depurador al algoritmo que efectúe el cálculo de la comprobación y 
observar el valor dado. Por supuesto, únicamente se procederá de esta manera cuando el 
área de datos objeto de la comprobación no se modifique con posterioridad. 


Por último, ha de tenerse en cuenta qué hacer con el valor de comprobación 
calculado. No resultará suficiente realizar una sencilla comparación entre los valores 
correcto y el calculado puesto que resulta muy fácil de detectar y suprimir. Muchos 
mecanismos de seguridad modernos utilizan el valor calculado para descifrar los datos 
cifrados con el valor de comprobación correcto. 


Otros métodos 


Existen muchas otras formas de proteger un programa frente a la edición de su 
código. Las comprobaciones de integridad no constituyen el único método posible, sólo el 
más extendido (principalmente con las aplicaciones simples). Ya se ha hecho referencia a 
otros métodos alternativos que combinan distintas tecnologías de protección, por ejemplo, 
la modificación directa del código del programa mientras se está ejecutando. 


CAPÍTULO 7 


EL FORMATO PE Y SUS HERRAMIENTAS 


DESCRIPCIÓN DEL FORMATO DE FICHERO PE 


Probablemente resulte imposible determinar exactamente la procedencia de la 
especificación del formato de fichero PE, un formato de fichero nativo en todas las 
plataformas Win32. Seguramente provenga de un formato UNIX COFF (en inglés, 
“Common Object File Format”, en castellano: “formato de fichero objeto común”). 


El formato PE (en inglés, “Portable Executable”, en castellano, “ejecución 
portátil”), como su nombre indica, se aplica como formato universal a los ficheros 
ejecutables de todas las plataformas Win32. Las plataformas compatibles con este formato 
reconocerán y trabajarán con este tipo de fichero independientemente de la CPU en la que 
se ejecute el sistema operativo. Como todos los ficheros ejecutables de una plataforma 
Win32, a excepción de las librerías VxD y las DLLs de 16 bits, utilizan este formato, su 
estudio permitirá penetrar en los secretos de la programación del sistema. 


El siguiente esquema muestra la estructura básica de un fichero PE: 


Cabecera 
DOS MZ 


Sección 
DOS 


Cabecera 
PE 


Tabla de 
secciones 


Sección 1 


Sección 2 


Sección n 


La cabecera DOS MZ se incluye en el fichero sólo para mantener su compatibilidad 
con DOS. Cuando este fichero se ejecute en DOS, el sistema operativo lo considerará 
válido gracias a la cabecera DOS MZ y proseguirá su ejecución en la sección DOS. La 
inmensa mayoría de las actuales aplicaciones Win32 contienen aquí el famoso texto: “este 
programa no puede ejecutarse en modo DOS”. Algunos programas antiguos conservan en 
esta sección su versión para DOS. 


Cuando el sistema operativo reconoce el fichero con formato PE y lo procesa, el 
cargador PE busca en la cabecera DOS MZ la ubicación de la cabecera PE para ejecutarla 
saltándose la sección de DOS. Seguramente estará aquí almacenada la estructura más 
importante del fichero PE: la denominada IMAGE NT HEADERS. A continuación se 
describirá dicha estructura con mayor detalle. 
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El contenido real del fichero PE se divide en bloques de datos llamados secciones. 
Los datos no se dividen en bloques según sus atributos lógicos, sino sus atributos 
característicos, por ejemplo: sólo lectura, ejecutable, escribible, etc. Por lo tanto, no deben 
considerarse la secciones como bloques lógicos de datos, código, etc. Aunque en algunos 
casos ocurra así, téngase en cuenta que todo depende de los atributos. Puede resultar algo 
confuso, pero hay buenas razones para ello. Cuando se carga un fichero en memoria, se 
puede detectar con mucha rapidez aquellos atributos asignados a lugares concretos de la 
memoria. 


Conforme el contenido del fichero se divida en secciones, será preciso guardar en 
algún lugar la información que las describa: su ubicación, tamaño, las características 
anteriormente mencionadas, etc. Éste constituye precisamente el objetivo de la tabla de 
secciones. Es un campo de estructuras, donde cada ítem de la estructura contiene 
información sobre una sección. De manera que si un fichero PE contiene, pongamos por 
ejemplo, cuatro secciones, este campo contendrá cuatro ítems (en circunstancias 
normales). 


DESCRIPCIÓN Y FUNCIONAMIENTO DEL 
COMPRESOR-CODIFICADOR PE 


Tras haber leído las secciones precedentes de este libro, el lector seguramente ya se 
habrá percatado de que el modo de protección más extendido contra el software pirata sea 
probablemente el uso de los compresores-codificadores PE. Se crearon a causa de la 
estructura compleja pero uniforme de los ficheros PE. Su diseño principal se basa en la 
codificación (o en la compresión) de secciones individuales de cualquier fichero PE y su 
descodificado en tiempo de ejecución, lo que imposibilita prácticamente la edición directa 
del código de programa. Al código de control, que, además de facilitar su descodificación, 
otorga integridad funcional al fichero prescindiendo de cualquier software complementario 
para su ejecución, se le pueden añadir elementos de protección complementarios no 
obligatorios. Algunos de los compresores-codificadores PE actuales se centran más en 
disminuir el tamaño que en proteger el programa. 


Por tanto, se puede afirmar que los compresores-codificadores PE constituyen una 
protección compleja que permite añadir distintos elementos de protección a un programa 
existente. El fichero no podrá editarse mediante un editor hexadecimal (debido a la 
codificación o a la compresión), ni tampoco desensamblarlo (si bien, estrictamente 
hablando, sí se puede desensamblar, si bien el código codificado no tendrá ningún sentido) 
y resultará muy difícil depurar o volcar cuando se combine con otras técnicas de 
protección complementarias. 


Como ya se indicó con anterioridad, el objetivo principal consiste en evitar la edición 
del programa. El resto normalmente constituye una protección contra el intento del cracker de 
descifrar manualmente el fichero para editar el programa. A los compresores-codificadores PE 
se les puede considerar protecciones de otras protecciones que ya existan dentro del programa 
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(como la comprobación de la presencia del CD, duración limitada, etc.). Existe un grupo 
especial de compresores-codificadores PE con sistemas de protección complejos (normalmente 
de tipo comercial) que ya incluyen estas protecciones. Al emplearlas, por ejemplo, se puede 
alterar un programa para que se convierta en una versión en demostración con duración 
limitada. 


Al igual que sucedía con otro tipo de protecciones y programas, aún se puede llevar 
a cabo la edición, no sólo empleando un editor hexadecimal directamente, sino también 
sobrescribiendo la memoria. Existen muchos compresores-codificadores PE que resultan 
vulnerables por no considerar la posibilidad de que pueda modificarse el código de 
programa. 


Creación de un codificador o compresor PE 


En primer lugar, debe añadirse el código de control del compresor-codificador PE al 
fichero. No se debiera confiar, sin embargo, en el suficiente espacio libre que tenga una de 
las secciones para este propósito. La opción más sencilla (pero no la más segura) consiste 
en añadir una nueva sección del tamaño oportuno al fichero. No obstante, existen 
codificadores PE que buscan espacio libre para calcular la ubicación del fichero donde 
debiera añadirse el código, e incluso lo dividen en pequeñas secciones. 


La situación cambia ligeramente con los diferentes tipos de compresores- 
codificadores. Algunos pretenden alcanzar la mejor compresión posible y reorganizar el 
fichero entero en sus mínimas partes; otros emplean un procedimiento completamente 
distinto. 


Los datos tendrán que redirigirse al código de control una vez que quede 
incorporado al fichero. Frecuentemente es el propio código añadido el que se encarga de 
descifrar y realizar otras funciones para controlar el código original del programa. Si bien 
éste es el método más extendido, no representa en absoluto la única solución posible; por 
ejemplo, se pueden emplear varios hilos en el código de control. 


La última cuestión que abordará esta sección atañe a las funciones importadas 
utilizadas por el programa. El fichero al que se añade el código de control no tiene 
necesariamente que importar todas las funciones que invoque: habrá que contemplar un 
método alternativo para importarlas. 


Aquí concluye la descripción y funcionamiento general de un compresor- 
codificador PE típico. 
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Desventajas de los compresores-codificadores PE 


Posiblemente la peor desventaja de los compresores-codificadores PE resida en su 
reversibilidad: tan sencillo como resulta su aplicación a un fichero, así de sencillo resulta 
su eliminación mediante un cierto tipo de descompresor-descodificador universal una vez 
el sistema de protección haya quedado anulado. Esto representa una desventaja frente a 
otros tipos de protección, puesto que resultará fácil y rápido suprimir la protección de un 
mayor número de programas codificados con el mismo compresor-codificador PE. Ahora 
bien, suprimir un tipo común de protección exige tanto tiempo como el empleado con un 
descodificador. 


Todo depende principalmente de cómo se programe el compresor-codificador PE. 
Algunos de ellos emplean diversos métodos de generación aleatoria y procesamiento de, 
por ejemplo, el código de control, las rutinas descodificadoras, etc. Obstaculizando, 
incluso imposibilitando la programación de un descompresor-descodificador universal. 


Algunos compresores-codificadores PE 
ASPACK 


Este programa de compresión alcanza, sin lugar a dudas, el mejor nivel de reducción 
de ficheros PE de entre todos los del mercado. Su algoritmo de compresión, cuyos 
resultados superan a los ficheros de tipo ZIP o RAR, constituye el núcleo de un compresor 
PE denominado ASProtect. 


Ce Aspack212 2% eS 
Win32 EXE, DLL compresor 
Registered to: 
z E UNREGISTERED 
Version 2.12 30 days 


Open File | Compress Options | About | Help | 


¡Y Use Windows DLL loader 


IV Create backup copy [bak file) T” Preserve extra data 


j 
j 
| 

IV Auto run after loading TT Add into context menu | 

3 


TT Én La Section's name 
a A —_———, 
3 ] 7 Language 
Unregistered version. Options are nol saved. 


Figura 7-1. La interfaz de ASPack se asemeja mucho a la de ASProtect 
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El principal inconveniente de este compresor radica en la debilísima protección 
contra un depurador y la ausencia de defensas contra la edición del código memoria. Si 
además se considera que con un cargador se pueden superar fácilmente estos obstáculos, la 
protección del fichero comprimido se reducirá notablemente. 


Al igual que ASProtect, ASPack demuestra una protección ligeramente superior al 


resto de la tabla de importaciones original, dificultando algo más los volcados de memoria. 
No obstante, un cargador evita realizar volcados de memoria. 


CODESAFE 


¿odeSafe for Win95/NT Ver3.0 /Unregi: Left 00 Program: 


Figura 7-2. Las escasas alternativas del programa CodeSafe 


Este compresor-codificador PE se puede utilizar con todas las plataformas Win32. 
Su comprensión dista mucho de las mejores y apenas se puede comparar con el compresor 
anterior. No obstante, incluye propiedades excelentes para dificultar la vulneración del 
fichero protegido. Las direcciones de las funciones importadas no se calculan mediante el 
método estándar de invocación de la función API, GetProcAddress, sino que se utiliza 
un método bastante nuevo e infrecuente a partir del formato PE. Su autor, Zhang De Hua, 
demostró ser un gran experto en este tipo de formato. 
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Aunque se comprueben puntos de corte bpx con los primeros cinco bytes de cada 
función importada en el fichero protegido, parece que el autor se olvidó de los tipos de 
puntos de corte restantes. 


NEOLITE 


Parecido a ASPack, el compresor NeoLite alcanza una compresión excelente, 
Desgraciadamente no se le puede pedir mucho más a este programa. La rutina de 
descompresión no contiene ningún elemento de protección, el propio programa puede 
inclusive descomprimir el programa comprimido. Todo ello demuestra que su objetivo 
primordial fue la reducción del tamaño del fichero PE más que su protección. Pudiera 
resultar útil para los desarrolladores profesionales de software que, con un concepto 
diferente de la protección, tan sólo exigen una compresión rápida y de calidad. 


NFO 


NFO es un codificador PE fabuloso, obviamente centrado en la protección de 
ficheros PE contra el cracking. Aplica un gran número de trucos antidepurador y 
antidesensamblador que bien pudiera costar algún dolor de cabeza al más experimentado 
cracker. Lástima que el fichero codificado sólo funcione con Windows 9x/Me, lo que 
restringe su uso significativamente. 


PE-COMPACT 


[Ea pECompactv1.84 AAA RA 
Configuration Help 


Filename | Browse | 


Compress 
| 


Operation: 
6 Compress Application 


Compress Dynamic Link Library 
Trim/Optimize Only 
(O Trim and Install Plugins 


3 vi 4 Pasos Conan 


Progress 
[ PECompact v1.84, 91999-2002 Collake Software. ] 


Figura 7-3. PE-compact 
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Éste es otro compresor PE más preocupado en la reducción del tamaño del fichero 
que en su protección. El programa utiliza dos algoritmos de compresión. El primero, 
basado en la librería Aplib, mundialmente conocida, y el segundo, creado por el autor de 
PE-compact, denominado JCALG. De libre distribución, obtiene muy buenos resultados y 
le coloca entre los mejores candidatos de los compresores del futuro. 


La rutina de descompresión no incluye ningún elemento de protección, con lo que, 
como en los casos anteriores, resulta muy sencilla la descompresión manual. 


PE-CRYPT 


PE-L+ypk 1.02 
Flle Build 


al elel ex 


ET 


y General 
TF Create Backup File (*. == 
TT Virus Heuristic Enable Hooking of API functions 
MÍ Enable Compresión — Erase PE Header 
SHE Disable TLS Support 


Import Hiding 


| £” Enable Compression 
£” Enable Encryption 


IV CRE Watnings 


| £% Display Window on CRC Error 
2 O 


(* Relocation Encryption (1 2bit) 
ES Relocation Encryption (16bit) 


Figura 7-4. Las opciones de PE-Crypt contra el cracking 


PE-Crypt ilustra bien el uso que se puede hacer del SMC. Este excelente compresor- 
codificador PE está enteramente basado en el SMC y lo aplica en gran medida. Su especial 
diseño imposibilita prácticamente cualquier intento de depuración o de desensamblaje, 
desesperando a quien lo intente. Es más, permite añadir a la rutina de descodificación otros 
algoritmos antidepuración o de supervisión de puntos de corte bpx y bpm. 


El programa solventó los errores de sus versiones anteriores al añadir una opción 
que permitiera a ciertas rutinas evitar la edición del código del programa en memoria. 
Desgraciadamente, algunos de estos métodos no son compatibles con Windows 
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NT/2000/XP, con lo que los programas así protegidos sólo funcionarán con Windows 
9x/Me. 


Puesto que el código íntegro de la rutina de descodificación está programado con 
SMC, se complica muchísimo la tarea, anteriormente fácil, de detectar algoritmos 
antidepurador y antidesensamblador. 


Desafortunadamente, incluso para este soberbio compresor-codificador PE existe 
descodificador. Se llama Bye PE Crypt. Ahora bien, si los autores, dos bien conocidos crackers, 
pusieran un poco más de esfuerzo en el desarrollo de este producto, PE Crypt volvería a ser 
indiscutiblemente uno de los mejores compresores-codificadores del mercado. 
Desgraciadamente, la ausencia de nuevas versiones sugiere que su desarrollo se ha paralizado. 


PE-SHIELD 


PE-Shield representa uno de los codificadores PE legendarios. Se hizo famoso al no 
existir durante mucho tiempo descodificador universal que lo anulase. Su excelente diseño 
estaba orientado precisamente a ello. Aplicaba métodos estándar de protección contra 
descodificadores genéricos, como ProcDump, algoritmos antirastreo (evitan rastrear la 
ejecución del programa) y, lo más importante, codificación polimórfica, empleado por vez 
primera en este codificador. 


El bucle de descodificación también contiene rutinas de defensa frente a los puntos 
de corte (puntos de corte hardware incluidos) y contra los depuradores. El autor del 
programa, Anakin, un maestro en esta verdadera especialidad, creó dichas rutinas. 


Para este codificador PE excepcional se creó un descodificador universal 
denominado UnPeShield. Ciertamente, su autor merece un gran respeto, puesto que 
programar un descodificador de análisis heurístico, en este caso no existe otra alternativa, 
no es tarea nada fácil. 


PETITE 
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Petite 2.2, copyright 1998-99 lan Luck. 
SHAREWARE... see REGISTER.TXT for details. 


Figura 7-5. Cómoda interfaz de Petite 
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Debido a su alto precio, este compresor se utiliza principalmente en el sector 
comercial. Si bien no llega a la compresión alcanzada por el imbatible ASPack, obtiene 
muy buenos resultados. 


Este producto cae más bien dentro de la categoría de herramientas de compresión 
más que de protección. Aunque la rutina de descodificación contenga algo parecido a un 
algoritmo antidepurador, su diseño no llega a los estándares actuales. No supone ningún 
obstáculo la descodificación manual del fichero protegido, lo que le descarta para realizar 
una buena protección. 


SHRINKER 


Menos por más. Así es cómo se podría describir este compresor-codificador PE de 
Blink Inc. No es que sea un mal producto. Consigue una compresión más que decente e 
incorpora un par de algoritmos antidepurador sencillos. Ahora bien, su precio no está a la 
altura de sus cualidades, resulta preferible optar por un compresor-codificador PE 
diferente. Cosa que no pone en duda ni siquiera su bien diseñada interfaz de usuario. 
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Figura 7-6. Opciones de UPX 


Lento pero seguro. Los autores de este compresor-codificador PE se atuvieron a esta 
máxima y acertaron. Durante el increíble período de dos años, este producto se probó y 
modificó hasta que quedó lista su versión definitiva (no beta). Tantos esfuerzos obtuvieron 
su recompensa: UPX (“Empaquetador Definitivo para Ejecutables”, en inglés “Ultimate 
Packer for Executables”), de merecido nombre, constituye el compresor-codificador PE 
más universal. No sólo soporta plataformas Win32, también DOS e incluso linux. Sus 
resultados al comprimir son equiparables a los de ASPack. 
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Lástima que sus autores invirtieran la mayor parte de su tiempo eliminando todo 
tipo de errores e inconvenientes de este programa (que, como contrapartida, le convierten 
en uno de los más fiables) y olvidaran en cierta medida la posibilidad de utilizarlo para 
algo más que comprimir. El que además de comprimir descomprima demuestra esta 
afirmación. 


Este programa se ha hecho infame por su uso con troyanos y virus, reduciendo sus 


tamaños (característica muy útil cuando el virus se manda por correo electrónico) y 
dificultando mucho su detección. 


WWPACK32 


+4 


2003-05-17 20:27:04 Directory 
189952 2003-05-17 20:27:04 WWP32 EXE 
[8] untar.dll 53248 2003-05-17 20:27:04 + Win32 DLL 
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Figura 7-7. La interfaz de usuario de WWPack se asemeja a la de WinRAR 


Este compresor PE no destaca entre los de calidad superior. Resulta evidente que 
los autores pusieron más empeño en el manejo del programa, simple, intuitivo y accesible 
incluso para un absoluto principiante. Desgraciadamente, carece de cualquier opción de 
seguridad. No es una gran cosa: el nivel de seguridad resulta prácticamente inexistente, y el 
único elemento de protección dado al fichero comprimido se reduce a unas simples rutinas 
de antidesensamblaje que pueden perfectamente controlarse con IDA. 


La descompresión manual de fichero protegido es un juego de niños y tampoco es 
muy buena la compresión resultante. 
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FORMATO DE FICHERO PE 


Comprobación del formato PE 


Debido a las formidables dimensiones del formato PE, nunca se puede afirmar con 
rotundidad si un fichero cumple cabalmente el formato. Para ello, debería supervisarse la 
exactitud de todas las estructuras del fichero. Como es prácticamente imposible, sólo se 
suele comprobar el formato PE de las estructuras más importantes. Por supuesto, siempre 
dependerá del autor el grado de exactitud exigido con los resultados de la operación. 


Probablemente el mejor compromiso en este caso consista en comprobar la parte 
más importante de un fichero PE, esto es, su cabecera PE. La cabecera contiene una 
estructura denominada IMAGE NT HEADERS, con el siguiente formato (extraído del 
fichero winnt.h): 


typedef struct _IMAGE NT HEADERS ( 

DWORD Signature; 

IMAGE FILE HEADER FileHeader; 

IMAGE OPTIONAL HEADER32 OptionalHeader; 
) IMAGE NT_HEADERS32,*PIMAGE_NT_HEADERS32; 


e Signature contiene el valor 50h, 40h, O, O, es decir, la secuencia “PE” con ceros al 
final. Microsoft definió este valor como una constante denominada 
IMAGE NT SIGNATURE. 


e  Laestructura FileHeader contiene información sobre la división física del fichero: 
nombre de secciones, información más detallada del fichero, etc. 


e La estructura OptionalHeader contiene información sobre la división lógica del 
fichero PE, como la dirección de Program Entry Point, etc. 


Si se deseara adquirir la estructura de IMAGE NT HEADERS, deberá invocarse la 
función ImageNtHeader definida en la librería imagehlp.dll dedicada a trabajar con 
ficheros PE. Lógicamente, primero habrá de cargarse el fichero pertinente en memoria. El 
proceso podría ser el siguiente: 


PIMAGE_NT_HEADERS pImageNT; 

DWORD NOBR; 

HANDLE File = CreateFile(“nombre del fichero”, GENERIC_READ, 
FILE SHARE READ, NULL, OPEN_EXISTING,FILE_ATTRIBUTE NORMAL, 
NULL) ; 

//obtención del manejador del fichero 
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if (File == INVALID HANDLE VALUE) 
MessageBox ("¡El fichero no puede abrirse para su 
lectura!”, NULL,MB_OK |MB_ICONINFORMATION) ; 
return; 


) 


DWORD FileSize = GetFileSize (File,NULL); 
BYTE *pMem = new BYTE [FileSizel ; // asignación de 
// memoria 
ReadFile (File, pMem, FileSize, £NOBR, NULL) ; // carga del 
// fichero en memoria 


pImageNT = ImageNtHeader ( (VOID*)pMem); //obtención de la 
// estructura 


IMAGE _NT_HEADERS 
if (pImageNT == 0) // ¿fichero PE? 


MessageBox (” ¡Fichero con formato PE incorrecto!”, 
NULL, MB_OK |MB_ICONINFORMATION) ; 

CloseHandle (File); 

delete pMem; 

return; 


) 


MessageBox (" ¡Fichero con formato PE correcto!” NULL,MB_OK 
| MB_ICONINFORMATION) ; 


CloseHandle (File) ; 
delete pMem; 


Si al invocar la función ImageNtHeader, se obtiene un resultado satisfactorio, el 
fichero cumplirá con el formato PE. En caso contrario, el fichero carecerá de la estructura 
y, por tanto, no resultará válido. 


Ahora bien, de no conformarse con las innecesariamente complicadas, y con 
frecuencia poco eficaces, librerías de ayuda, utilícese el procedimiento siguiente. De nuevo 
resulta preciso obtener la estructura IMAGE_NT_HEADERS y comparar su variable 
Signature con la constante IMAGE _NT_SIGNATURE. 


Ahora bien, ¿cómo encontrar la dirección de la estructura IMAGE NT_HEADERS? 
La cabecera DOS MZ, definida por la estructura IMAGE_DOS_HEADERS, tiene el 
siguiente formato: 


typedef struct _IMAGE DOS HEADER ( // Cabecera DOS .EXE 
WORD e magic; // número mágico 
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WORD e cblp; // bytes de la última página del fichero 
WORD e cp; // páginas del fichero 


WORD e _crlc; //  reubicaciones 
WORD e cparhdr; // tamaño de la cabecera en los 
// párrafos 

WORD e_minalloc; // mínimos párrafos extra necesarios 
WORD e_maxalloc; // máximos párrafos extra necesarios 
WORD e _ss; // valor SS inicial (relativo) 
WORD e_sp; // valor SP inicial 
WORD e _csum; // Comprobación 
WORD e_ip; // valor IP inicial 
WORD e_cs; // valor CS inicial (relativo) 
WORD e _lfarlc; // dirección del fichero de la tabla de 

// reubicaciones 
WORD e ovno; // número de superposición 
WORD e_res [4]; // palabras reservadas 
WORD e_oemid; // ¡identificador OEM (para e _oeminfo) 
WORD e_oeminfo; // información OEM; propio de e _oemid 
WORD e_res2 [10]; // palabras reservadas 
LONG e_lfanew; // dirección del fichero de la nueva 


// cabecera exe 
)IMAGE_DOS HEADER, *PIMAGE_DOS_HEADER; 


La última variable e 1fanew almacena la dirección de la cabecera PE del fichero. 
La primera palabra de la estructura IMAGE_NT_HEADERS guarda los valores 4Dh, 5Ah, 
esto es, “MZ” (esto es, la cabecera DOS MZ), también definida por Microsoft como la 
constante para IMAGE_DOS_SIGNATURE, es decir, en la variable e magic, y por lo 
tanto también en la primera palabra de todo el fichero. 


Si se desea una seguridad absoluta, se podrá probar la validez de la estructura 
IMAGE_DOS_HEADER comparando la primera palabra del fichero con la constante 
anteriormente mencionada y entonces utilizar la dirección de la cabecera PE a partir de su 
variable e 1fanew. 


DWORD NOBR; 
LPBYTE Buffer; 


HANDLE File = 

CreateFile (“nombre del fichero”, GENERIC_READ, FILE SHARE 
_READ, NULL, OPEN | EXISTING, FILE _ATTRIBUTE NORMAL, NULL) ; 

//obtención del manejador del fichero 

if (File ==INVALID HANDLE VALUE) 

( 

MessageBox("¡El fichero no se puede abrir en modo 
lectura!” ,NULL,MB_OK | MB_ICONINFORMATION) ; 
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return; 


) 


DWORD FileSize = GetFileSize(File,NULL); 


BYTE *pMem = new BYTE [FileSizel; // asignación de 
// memoria 
ReadFile (File, pMem, FileSize,£NOBR, NULL) ; // carga 


// del fichero en memoria 
Buffer = pMem; 


if (*((LPWORD) Buffer) == IMAGE_DOS SIGNATURE) 1/7. ¿MZ? 


LPDWORD Signature = 
(LPDWORD) (Bu£fer+* ( (LPDWORD) Buffer+15)); 


if (*Signature != IMAGE _NT_SIGNATURE) // ¿PE? 
MessageBox (” ¡Fichero con formato PE 
incorrecto!” ,NULL,MB_OK |MB_ICONINFORMATION) ; 


else 
pm, 


MessageBox (" ¡Fichero con formato PE correcto! 
NULL,MB_OK |MB_ICONINFORMATION) ; 


) 


else 
MessageBox (” ¡Fichero con formato PE 
incorrecto!” ,NULL,MB_OK |MB_ICONINFORMATION) ; 


CloseHandle (File); 
delete pMem; 


Cabecera PE 


Hasta ahora se ha descrito brevemente la arquitectura de la cabecera PE en las 
secciones anteriores de este capítulo. Se crea mediante la estructura 
IMAGE NT HEADERS, donde juega un papel señalado la variable Signature. 
Seguidamente se examinará el resto de esta estructura, Consta de dos estructuras 
principales denominadas FileHeader y OptionalHeader. A continuación se 
presenta la arquitectura de la primera: 


typedef struct _IMAGE FILE HEADER ( 
WORD Machine; 
WORD NumberOfSections; 
DWORD TimeDateStamp; 
DWORD PointerToSymbolTable; 
DWORD NumberO0fSymbols; 
WORD SizeO0fOptionalHeader; 
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WORD Characteristics; 
JIMAGE_FILE HEADER, *PIMAGE_FILE_ HEADER; 


Machine indica el nombre de la máquina. En el caso de la plataforma Intel este 
valor equivale a la constante IMAGE FILE MACHINE 1386, esto es, 14Ch. 


NumberOfSections contiene el número de secciones del fichero. Recuérdese 
bien esta variable cuando, en la parte del capítulo dedicada a los codificadares PE, deba 
añadirse una sección nueva al fichero. 


Las siguientes tres variables carecen aquí de interés. En TimeDateStamp se 
guarda la fecha y la hora de creación del fichero, PointerToSymbolTable y 
Number0f Symbols se utilizan en la depuración. 


SizeO0fOptionalHeader, como su nombre sugiere, indica el tamaño de la 
estructura OptionalHeader. 


Characteristics: características del fichero, por ejemplo, si es un fichero EXE 
o DLL. 


La última parte de la estructura IMAGE NT_HEADERS consiste en una estructura 
denominada OptionalHeader. Por ser muy larga, sólo se destacarán sus partes más 
importantes: 


typedef struct _IMAGE OPTIONAL HEADER ( 
// 
// Campos estándar. 


// 


DWORD AddressOfEntryPoint; 

// 

// Campos NT complementarios. 

1/ 

DWORD ImageBase; 

DWORD SectionAlignment ; 

DWORD FileAlignment; 

WORD MajorOperatingSystemVersion; 
WORD MinorOperatingSystemVersion; 


DWORD Size0f Image; 
DWORD SizeOfHeaders; 
DWORD CheckSum; 

WORD Subsystem; 
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IMAGE DATA DIRECTORY DataDirectory 
[IMAGE _NUMBEROF DIRECTORY ENTRIES]; 


)IMAGE OPTIONAL HEADER32,* PIMAGE OPTIONAL HEADER32; 


+ AddressOfEntryPoint (posteriormente denominado Program 
Entry Point) es una RVA (véase más adelante) de la primer 
instrucción del código de programa que arrancará su ejecución. 


+ ImageBase representa la dirección de carga preferida para el fichero PE. 
En la mayoría de las ocasiones este valor es 400000h. 


La dirección de carga preferida constituye la dirección de arranque en la que el 
cargador PE intentará cargar el fichero en memoria. De manera que si el valor fuera 
400000h, el fichero quedará cargado en un espacio de memoria a partir de la dirección 
00400000. El cargador PE sólo será capaz de cargar el fichero en esta dirección siempre 
que un proceso distinto no esté ya empleando este espacio de direcciones. Si fracasara, se 
elegiría una dirección nueva para cargar el fichero memoria. El fichero permanecerá 
operativo incluso tras esta operación gracias a la RVA, nueva sigla cuyo significado se 
describirá posteriormente. 


Con frecuencia se piensa que vivimos en un mundo de sistemas operativos basados 
en la multitarea. Debe precisarse que aunque el usuario pueda pensar que se están 
ejecutando más operaciones a la vez, la realidad es bien distinta. El sistema tan sólo salta 
de una a otra muy rápido (lo que constituye una explicación simplificada. Si se deseara 
más información sobre este asunto, Internet está repleto de material al respecto). Esto 
explica que el espacio de direcciones referido por ImageBase no esté ya ocupado al 
arrancar el primer programa y le parezca al usuario que los procesos individuales 
compartan sus recursos (por ejemplo, que cinco recursos utilicen la misma memoria). 


+ SectionAlignment determina el alineamiento de las secciones en 
memoria. Normalmente se define con el valor de 1000h, lo que indica que 
cada sección debe comenzar en una dirección de memoria múltiplo de 
1000h. Por lo tanto, si la primera sección comenzara en la dirección 
00407000 por ejemplo, aunque su tamaño fuera de un solo byte, la segunda 
sección empezaría en la dirección 00408000. 


+ FileAlignment se parece a SectionAlignment, la única diferencia 
reside en que determina el alineamiento físico de las secciones individuales 
directamente en el fichero en vez de en memoria. Normalmente tiene el 
valor de 200h. 
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e MajorSubsystemVersion y MinorSubsystemVersion, de más 
importancia aquí, determinan la versión del subsistema Win32. 


e SizeOfImage contiene el tamaño total de la imagen del fichero tras 
haberse cargado en memoria, se define como la suma de todas las 
cabeceras y secciones, alineamiento incluido. 


e SizeOfHeaders representa la suma de todas las cabeceras (incluyendo 
la sección DOS) y tabla de secciones. Constituye, por tanto, la ubicación de 
la primera sección en el fichero. 


+  Subsystem indica el subsistema NT al que va destinado el fichero. La 
mayoría de los programas Win32 definen el valor Windows GUI o 
Windows CUI (aplicación de consola, en inglés “console application”). 


e DataDirectory, campo de la estructura IMAGE_DATA DIRECTORY 
con RVAs de estructuras importantes del fichero PE, por ejemplo, las 
tablas de importación o exportación. 


Tabla de secciones 


La tabla de secciones está representada en el fichero PE por estructuras 
IMAGE SECTION HEADER. El número de ítems en este campo y, por tanto, también el 
número de estas estructuras se guarda en la variable Number0fSections de la 
estructura IMAGE FILE HEADER, 


A continuación se describe la arquitectura de la estructura 
IMAGE _SECTION_HEADER: 


typedef struct IMAGE SECTION HEADER ( 
BYTE Name [IMAGE SIZEOF SHORT NAME]; 
union ( 
DWORD PhysicalAddress; 
DWORD VirtualSize; 
Misc; 
DWORD VirtualAddress; 
DWORD SizeOfRawData; 
DWORD PointerToRawData; 
DWORD PointerToRelocations; 
DWORD PointerToLinenumbers; 
WORD NumberOfRelocations; 
WORD NumberOfLinenumbers; 
DWORD Characteristics; 
) IMAGE SECTION HEADER, *PIMAGE SECTION HEADER; 


ORA-MA 
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DIRECCIONES 


Name contiene un máximo de ocho caracteres, indica el nombre de la 
sección y no puede terminar en un carácter nulo. 


Union Misc está, de hecho, representado por la única palabra doble, 
VirtualSize. Esta variable contiene el tamaño de la sección en 
memoria sin alineamiento, según el valor SectionAlignment. 


VirtualAddress determina el valor RVA de la sección. 


SizeOfRawData determina el tamaño real de la sección en el fichero, 
incluyendo el alineamiento FileAlignment. 


PointerToRawData es un puntero al principio de la sección 
correspondiente en el fichero. 


Characteristics describe las características de los datos de la 
sección, por ejemplo, de sólo lectura, lectura y escritura, código ejecutable, 
etc. 

VIRTUALES, 


MATERIALES Y VIRTUALES 


RELATIVAS (RVA) 


La palabra virtual se refiere a información que indica la posición en memoria. 
Material, por otro lado, indica la ubicación directamente en el fichero. 


Se ilustrará todo con el siguiente ejemplo. Ábrase con un editor PE (uno de los 
mejores se incluye en el CD adjunto) el fichero notepad.exe (se asume que todo el mundo 
tiene este fichero en su disco). Se obtendrán los valores siguientes: 


Name VirtualSize este SizeOfRawData. a a taa 
Virtual) (Tamaño material) material) 

text 000065CAh 00001000h 00006600h 00000600h 

«data 00001944h 00008000h 00000600h 00006C00h 

ESTO 00006000h 0000A000h 00005400h 0007200h 
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Ábrase ahora el fichero con algún editor hexadecimal para situarse en la ubicación 
(desplazamiento) PointerToRawData, esto es, 600h. Esta nueva situación señalará el 
principio de la primera sección del fichero. Si se añade a este valor el tamaño de la propia 
sección (SizeOfRawData), es decir, 600h + 6600h, la ubicación lógica será el principio 
de la segunda sección denominada .data (6C00h). Muy sencillo. 


Ahora bien, no resulta tan simple en el caso de la memoria. ImageBase, la 
dirección de carga preferida, causa ciertas ambigúedades que confunden a muchos 
principiantes. 


Seguramente se recordará que este valor sólo se utilizará si no existiera ya un 
proceso distinto utilizando ese espacio especifico de direcciones. Si no se consiguiera la 
asignación de memoria indicada por esta dirección, deberá emplearse una dirección 
diferente. Imagínese por un momento que todos los valores importantes del formato PE 
apuntan directamente a una dirección específica de la memoria (como sucede con las 
variables materiales de este fichero). El cargador PE tendría entonces que sustituirlas todas 
por otras nuevas direcciones. 


Es aquí donde se utiliza la dirección virtual relativa (RVA, en inglés “Relative 
Virtual Address”), sirve de puntero a la ubicación en memoria sin emplear el valor de 
ImageBase. Tras sumar el valor de RVA al de ImageBase, se obtiene una ubicación 
real de memoria. La RVA se convierte entonces en VA (dirección virtual, en inglés 
“Virtual Address”, no se confunda con la variable VirtualAddress, que de hecho es 
una RVA), con el valor real de la dirección en memoria (lo que resulta bastante lógico al 
omitir la palabra “relativa”). Todas las variables importantes del formato PE que describen 
posiciones de memoria (por ejemplo, VirtualAddress) contienen de hecho RVAs de 
estas posiciones de memoria. 


No obstante, aún no se han resuelto todos los problemas. Muchas instrucciones del 
fichero se refieren a valores absolutos de direcciones en memoria; por lo tanto, una nueva 
dirección de carga del fichero en memoria inutilizaría el fichero. Ésta es la razón de que el 
formato PE defina las llamadas reubicaciones; así, al corregir todos estos valores según la 
nueva dirección de carga, el fichero podrá funcionar con normalidad. 


Las reubicaciones se utilizan primordialmente con las librerías DLL, apenas tienen 
uso práctico con ficheros EXE. En circunstancias normales, debido a la multitarea, sólo se 
ejecuta un proceso, por lo que resulta prácticamente imposible ocupar la memoria señalada 
por el valor de ImageBase del fichero EXE creador del proceso. Por otra parte, muchas 
librerías DLL pueden ejecutarse dentro de un proceso (funciones de importación): así sí 
resulta posible ocupar ImageBase. Circunstancia solucionada mediante las 
reubicaciones. La única excepción en el caso de ficheros EXE se reduce a los casos en que 
exporten funciones. Si las funciones se importasen desde el fichero por el proceso, la 
situación resultaría muy similar a la de las librerías DLL; caso también resuelto con las 
reubicaciones. 
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Si la ImageBase de un fichero EXE del proceso específico resultase ocupada, 
revelará normalmente a algún otro error, que posiblemente colapse el programa incluso el 
sistema operativo. 


Algunos lenguajes de programación, como Delphi, añaden por omisión 
reubicaciones dentro de cada uno de sus programas: casi siempre se encuentran 
reubicaciones en los programas creados con estos lenguajes. 


Volvamos al ejemplo del Bloc de notas (notepad.exe). Si se desease examinar el 
principio de la primera sección de este programa en memoria con un depurador, añádase el 
valor de ImageBase (en este caso 1000000h) a la dirección virtual (en este caso 65CAh), 
se obtendrá el valor 10065Cah, es decir, la dirección real de la primera sección del 
programa en memoria. 


RVA, suma de la primera sección (VirtualAddress) con su tamaño 
(VirtualSize), contiene el valor 75CAh, que constituye la RVA de la posición en 
memoria donde termina la primera sección. Para obtener el principio de la siguiente 
sección de memoria, basta con alinear la sección según el valor SectionAlignment 
(en este caso, 1000h), cuyo resultado es 8000h. 


En ocasiones, diversas secciones del fichero no se alinean según ImageBase. Los 
cálculos se vuelven entonces mucho más complicados y confusos. Está de más explicar 
aquí cómo llevar a cabo estos cálculos. Resulta mucho más fácil utilizar algún programa 
que los ejecute. Dos de ellos se encuentran en el CD incluido en este libro. 


Tabla de importaciones 


La tabla de funciones importadas o, más brevemente, importaciones, y 
especialmente las funciones de importación en sí, constituye una de las piedras angulares 
de la arquitectura de la plataforma Win32. La sola palabra “importar” indica claramente el 
cometido de estas funciones. 


Una función importada consiste en una función invocada por el fichero PE, sin que 
el propio fichero la contenga. La tabla de importaciones del fichero contendrá toda la 
información necesaria para emplear las funciones importadas (nombre de la función, 
librería DLL, etc.) pero no la propia función. 


Para que un fichero PE importe una función, otro fichero PE debe exportarla. 
Normalmente las funciones se suelen exportar mediante librerías DLL, ciertamente muy 
extendidas. 


El último campo de la estructura IMAGE OPTIONAL HEADER, contenida dentro 
de IMAGE NT HEADERS incluye un campo de dieciséis estructuras 
IMAGE DATA DIRECTORY denominado DataDirectory. Cada una de estas 
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estructuras contiene información sobre el tamaño y RVA de algunas posiciones 
importantes del fichero. A continuación se expone la arquitectura de la estructura 
IMAGE DATA DIRECTORY: 


typedef struct IMAGE DATA DIRECTORY ( 

DWORD VirtualAddress; 

DWORD Size; 

)IMAGE DATA DIRECTORY,*PIMAGE DATA DIRECTORY; 


VirtualAddress es la RVA de la estructura correspondiente, y Size, su 
tamaño. 


A partir de los datos contenidos en la tabla siguiente se pueden determinar 
fácilmente los ítems más importantes del campo DataDirectory de estructuras 
IMAGE DATA DIRECTORY específicas y la información sobre los datos que contengan: 


Ítem del | Información 
campo 

0 Tabla de 
exportaciones 

1 Tabla de 
importaciones 

2 Recursos 

3 Excepción 

5 Reubicación base 

6 Depuración 

cl Derechos de autor 

9 Tabla TLS 

10 Cargar 
configuración 

11 Vínculo de 
importación 
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La segunda estructura de DataDirectory contiene información sobre la tabla 
importaciones. El valor de VirtualAddress en esta estructura será la RVA de la tabla 
de importaciones. Así se resuelve la búsqueda de la tabla de importaciones en el fichero. A 
continuación se examinará su estructura. 


La tabla importaciones consta de estructuras IMAGE IMPORT DESCRIPTOR. A 
continuación se presenta la arquitectura de esta estructura: 


typedef struct IMAGE IMPORT DESCRIPTOR ( 
union ( 
DWORD Characteristics; 
DWORD OriginalFirstThunk; 
d; 
DWORD TimeDateStamp; 
DWORD ForwarderChain; 
DWORD Name; 
DWORD FirstThunk; 
)IMAGE_IMPORT_DESCRIPTOR; 


Finaliza con una estructura llena de caracteres nulos. 


Cada estructura IMAGE _IMPORT_DESCRIPTOR contiene información sobre la 
librería desde la que se importarán las funciones. De manera que si el fichero importa, 
pongamos por caso, diez librerías, la tabla de importaciones 
IMAGE IMPORT DESCRIPTOR contendrá diez estructuras más una estructura final 
rellena con caracteres nulos (siempre que no se enlacen mal). 


El primer ítem de la estructura IMAGE _IMPORT_DESCRIPTOR es Union, que 
será sustituido por una variable de doble palabra: OriginalFirstThunk. Esta variable 
contiene la RVA de las estructuras IMAGE THUNK_DATA. El campo finaliza, al igual que 
con IMAGE IMPORT DESCRIPTOR, con una estructura rellena de caracteres nulos, 


Name es la RVA del nombre de la librería, esto es, el puntero RVA del nombre de 
la librería en formato ASCII, 


FirstThunk incluye la RVA de la segunda estructura IMAGE THUNK_DATA, 
idéntica a la señalada por OriginalFirstThunk. La diferencia entre estos dos campos 
reside en la sustitución realizada a los ítems en el campo apuntado por First Thunk con 
las direcciones reales de las funciones importadas cuando el cargador PE procesa las 
funciones importadas. El segundo campo donde apunta OriginalFirstThunk 
permanece invariable cuando el cargador PE necesita encontrar los valores originales de 
las estructuras IMAGE _THUNK_DATA. 
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La estructura IMAGE _THUNK_DATA ni siquiera debiera llamarse estructura puesto 
que sólo contiene el puntero RVA a otro estructura, IMAGE IMPORT DESCRIPTOR. 
Para evitar la confusión, resulta más preciso concebir esta estructura como un puntero a la 
estructura IMAGE IMPORT _BY NAME. El número de ítems en las estructuras 
IMAGE _THUNK_DATA es lógicamente idéntico al número de ítems de las estructuras 
IMAGE IMPORT BY NAME, que determinan el número de funciones importadas desde 
una librería. 


Finalmente en la estructura IMAGE_IMPORT BY NAME reside la información 
sobre la función importada. A continuación se expone la arquitectura de esta estructura: 


typedef struct _IMAGE IMPORT _BY NAME ( 

WORD Hint; 

BYTE Name [1]; 

)IMAGE_IMPORT_BY NAME, *PIMAGE_IMPORT_BY NAME; 


Hint no tiene aquí uso práctico. Señala la tabla de exportaciones de la librería 
desde la que se importa la función; el cargador PE lo utiliza para acelerar la búsqueda de 
las funciones importadas en la tabla de exportaciones de la librería. 


Name contiene el nombre de la función en formato ASCII Con tan pequeño 
espacio de almacenamiento no bastaría para guardar el nombre de la función, razón por la 
que Name tiene en realidad tamaño flexible. 


La situación se complica más cuando algunas funciones importadas carecen de 
estructura IMAGE _IMPORT_BY NAME. A estas funciones se las denomina funciones 
ordinales: no se las importa según su nombre, sino su posición. En este caso, la estructura 
IMAGE _THUNK_DATA no señala a la estructura IMAGE IMPORT _BY NAME. A estas 
funciones se las denomina funciones ordinales: no se las importa según su nombre, sino 
que su palabra final señala la posición de la función cambiando a 1 su bit más significativo 
(“MSB”, en inglés). 


Para probar con facilidad el MSB de doble palabra se definió la constante 
IMAGE ORDINAL FLAG32 con el valor 80000000h. Por lo tanto, si la posición de la 
función ordinal fuera ABCDh, IMAGE THUNK_DATA tendrá el valor 8OD00ABCDh. 


Tabla de exportaciones 


La parte anterior de este capítulo se centró en las funciones importadas. Sus 
contrarias son las exportadas. Su principio resulta muy sencillo. Si se desea importar 
funciones con un fichero PE, otro fichero PE tendrá que exportarlas. 
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Al igual que con las importadas, las funciones se pueden exportar según su nombre 
o ubicación (funciones ordinales). 


Considerando que el desarrollador apenas puede influir directamente en la 
ubicación de estas funciones, como en una librería DLL ya creada, la exportación O 
importación de las funciones ordinales puede resultar un poco laboriosa. 


La tabla de exportaciones puede localizarse, al igual que la tabla de importaciones, 
mediante el campo DataDirectory de la estructura IMAGE_DATA_DIRECTORY. La 
tabla queda definida por la estructura TMAGE_DATA DIRECTORY: 


typedef struct _IMAGE EXPORT DIRECTORY ( 
DWORD Characteristics; 
DWORD TimeDateStamp; 
WORD MajorVersion; 
WORD MinorVersion; 
DWORD Name; 
DWORD Base; 
DWORD NumberOfFunctions; 
DWORD NumberOfNames; 
DWORD AddressOfFunctions; 
DWORD AddressOfNames; 
DWORD AddressOfNameOrdinals; 
) IMAGE _EXPORT_DI RECTORY, *PIMAGE_EXPORT_D IRECTORY; 


AddressOfFunctions contiene la RVA del campo de direcciones de las 
funciones exportadas individuales. El múmero de ítems en este campo equivale a 
Number0f Functions. 


AddressOfNames contiene la RVA del campo de RVAs de los nombres de las 
funciones exportadas. El número de ítems en este campo equivale a Number0f Names. 


Si el fichero no exportase ninguna función ordinal, Number0f Functions y 
NumberOfNames tendrían el mismo valor. Caso contrario, la diferencia entre 
Number0f Functions y NumberO0fNames sería igual al número de funciones 
ordinales. 


AddressOfNameOrdinals señala a un campo de índices que interconecta los 
campos de nombres y de direcciones. Al representar este campo de índices cierto tipo de 
conexión entre los nombres de las funciones y sus direcciones, no resulta aplicable a las 
funciones ordinales. 


El campo al que señala AddressOfNameOrdinals contiene un número de 
ítems equivalente al campo de nombres. Cada ítem de este campo se relaciona con el 
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mismo ítem del campo de nombres. Razón por la que ambos campos deben procesarse 
simultáneamente. Una dirección se empareja a siempre con un nombre de función, pero no 
necesariamente ocurre lo contrario. 


El siguiente algoritmo puede utilizarse para calcular la RVA de una función 
exportada: 


//  EBX = AddressO0fNameOrdinals 
mov dx, [ebx] //  DX contiene el índice de las 
// posiciones en el campo de direcciones 
movzx edx,dx // completado con ceros 
shl edx, 2 1/ *4 
add edx,AddressO0fFunctions //  EDX = RVA 


Si se intentara colocar este algoritmo en un bucle con objeto de calcular las RVAs 
de todas las funciones exportadas, sería preciso aumentar el valor del puntero 
AddressOfNameOrdinals al campo de índices según el tamaño y del ítem de este 
campo, esto es, una palabra. Por supuesto, AddressOfNameFunctions no se ve 
aumentado. 


CONFIGURACIÓN DE UN CODIFICADOR PE 


Esta parte del capítulo estará dedicada a describir la programación de un codificador 
PE para que el lector pueda crear el suyo propio (Win32 EXE). Si se requiriese emplear el 
codificador con otros ficheros PE, por ejemplo DLLs, sería preciso alterar el 
procedimiento de creación del codificador en muchos aspectos. En este caso pudiera ser 
útil el algoritmo de reubicación incluido en la sección de referencia de este libro. 


Los ejemplos individuales se mostrarán de forma paulatina para poder crear el 
codificador PE paso a paso. 


A la hora de crear un codificador PE, siempre será necesario decidir dónde y cómo 
se añadirá el código de control del codificador. No ha de confiarse en que una sección 
tenga suficiente espacio para albergar este código. Resultará preferible una solución más 
sencilla: añadir al fichero una sección nueva del tamaño oportuno. 


Inclusión de una sección nueva en un fichero 


En primer lugar, debe cargarse el fichero en memoria y obtener el puntero a la 
estructura IMAGE NT HEADERS. 
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PIMAGE NT_HEADERS plImagenNT; 
DWORD NOBR; 


HANDLE File = 
CreateFile (“nombre del fichero",GENERIC_READ, FILE_SHARE 
_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL) ; 
// obtención del manejador del fichero 
// El fichero se abre con parámetro de 
//lectura, las modificaciones se 
//guardarán en otro fichero 


if (File == INVALID HANDLE VALUE) 

( 

MessageBox ("¡El fichero no se puede abrir en modo 
lectura!” NULL, MB_OK |MB_ICONINFORMATION) ; 
return; 


) 


DWORD FileSize = GetFileSize(File,NULL); 
BYTE *pMem = new BYTE [FileSize];  // asignación de 
// memoria 
for (DWORD i = 0; i < FileSize; i++) // ¡por si se 
// “borrase” la memoria 


pMem [il = 0; 


ReadFile (File, pMem, FileSize,NOBR,NULL);  // carga del 
// fichero en memoria 
pImageNT = ImageNtHeader ( (VOID*) pMem) ; // obtención 


//de la estructura 
/ /IMAGE_NT_HEADERS 
if (pImageNT == 0) 
( 
MessageBox (" ¡Fichero con formato PE 
incorrecto!” ,NULL,MB_OK |MB_ICONINFORMATION) ; 
CloseHandle (File); 
delete pMem; 
return; 


) 


A partir de este momento, se puede añadir una función nueva denominada 
AdáSection para añadir una nueva sección. Como primer paso, esta función tiene que 
ver si hay suficiente espacio en la tabla de secciones para incluir una más. Comprobación 
muy sencilla. Basta con calcular los tamaños de todas las cabeceras, las definiciones de las 
secciones individuales de la tabla de secciones más el espacio necesario para añadir la 
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definición de la nueva sección. Compárese entonces el resultado con el valor de 
SizeOfHeaders. Si fuera inferior que la suma resultante, obviamente no quedaría 
suficiente espacio libre en la tabla de secciones para definir una nueva. La diferencia entre 
estos dos valores representa el tamaño del espacio libre en la tabla de secciones. 


DWORD CPEcoderDlg::AddSection (BYTE *pMem, 
PIMAGE_NT_HEADERS pImageNT) 
( 
DWORD SecNum = pImageNT->FileHeader.NumberOfSections; 
// número de secciones 
DWORD SecSize = sizeof IMAGE SECTION HEADER; 
// tamaño de la definición de una sección 


DWORD Size = (SecNum+1)*SecSize; // tamaño nuevo de 
// definición en la tabla de secciones 
DWORD TotalSize = (DWORD) pImageNT- 
(DWORD) pMem+Size+sizeof IMAGE NT HEADERS; // suma 
// de los tamaños de todas 
// las cabeceras y definiciones 
// de las secciones 
DWORD HeadersSize = pImageNT- 
>OptionalHeader.SizeOfHeaders; 
if (TotalSize >HeadersSize) // ¿espacio suficiente 
//para una sección nueva? 


MessageBox (” ¡espacio insuficiente en la tabla de 
secciones!” ,NULL,MB_OK |MB_ICONINFORMATION) ; 
return 0; 


Al saber que se deberá escribir posteriormente en la mayor parte de las secciones 
(para codificar y descodificar datos principalmente), será necesario alterar sus 
características para permitir su escritura (mediante la función lógica OR 80000000h). 


También será preciso localizar cierta información sobre la última sección del fichero 
para poder colocar detrás la nueva. Todo ello se realizará de golpe mediante la siguiente 
función: 


IMAGE SECTION HEADER 
CPEcoderDlg::RvaToSection(PIMAGE NT HEADERS 
pImageNT,BYTE*pMem, DWORD AdrO0fSecTable,BOOL AdjustChar) 


E 


PIMAGE SECTION HEADER pSection; 
IMAGE SECTION HEADER Section; 
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DWORD vaddr; //  VirtualAddress 
memcpy (svaddr, (VOID*) (Adr0fSecTable+12),sizeof DWORD) ; 
pSection = ImageRvaToSection (pImageNT, pMem, vaddr) ; 
if (pSection == 0) 
( // no se procesó esta sección con la función 
// ImageRvaToSection 
DWORD vsize,raddr,rsize, characteristics; 
memcpy (£vsize, (VOID*) (AdrofSecTable+8),sizeof 


DWORD) ; 

memcpy (£rsize, (VOID*) (AdrofsecTable+16) ,sizeof 
DWORD) ; 

memcpy (Sraddr, (VOID*) (Adro0fSecTable+20),sizeof 
DWORD) ; 


memcpy (characteristics, (VOID*) (AdrofSecTable+36) 
,sizeof DWORD); 
Section.VirtualAddress = vaddr; 


//VirtualAddress 
Section.Misc.VirtualSize = vsize; //VirtualSize 
Section.PointerToRawData = raddr; 
//PointerToRawData 
Section.SizeOfRawData = rsize; //SizeofRawData 


if (AdjustChar) // modificación de las 
// características para permitir 
//escritura 
Section.Characteristics = characteristics | 
0x80000000; 


return Section; 


if (AdjustChar) // modificación de las 
// características para permitir escritura 


pSection->Characteristics = pSection- 
>Characteristics | 0x80000000; 


Section = *pSection; 
return Section; 


) 


Como se puede comprobar, el último parámetro de la función permite modificar sus 
características. Ello facilitará en el futuro utilizar esta función para localizar información 
cómodamente sobre la sección. 


La función se puede invocar de la siguiente manera: 


DWORD AdrOfSecTable; 
for (DWORD i = 0; i < SecNum; i++) 
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AdrO0fSecTable = (DWORD) pImageNT+sizeof 
IMAGE _NT_HEADERS+i* (sizeof IMAGE SECTION_HEADER) ; 
// puntero a la 
// tabla de secciones 
*pSection = 
RvaToSection (pImageNT, pMem, Adr0fSecTable, TRUE) ; 


) 


Desgraciadamente, la función ImageRvaToSection, que obtiene información 
de la sección en el puntero a la estructura IMAGE SECTION HEADER, no funciona muy 
bien ya que por alguna razón no puede procesar secciones no estándar (como las que 
contienen ceros en PointerToRawData o SizeOfRawData). Para evitar problemas y 
en caso de error, el valor se puede obtener manualmente mediante la función memcpy. 


En este caso, la utilización de la función ImageRvaToSection resulta 
lógicamente redundante, aquí se incluye para mostrar todas las opciones. Esta función se 
podrá utilizar de tarde en tarde para obtener información sobre una sección fácilmente. 


Ya se puede utilizar la información sobre la última sección del fichero para calcular 
los parámetros de la nueva sección: 


unsigned char Namel [8] = “.new”; 
DWORD *VirtualAddress = new DWORD; 
DWORD *VirtualSize = new DWORD; 
DWORD *SizeOfRawData = new DWORD; 
DWORD *PointerToRawData = new DWORD; 
DWORD *Characteristics = new DWORD; 


*VirtualAddress = PEAlign (pSection- 
>VirtualAddress+pSection->Misc.VirtualSize,plmageNT- 
>OptionalHeader.SectionAlignment); 

*VirtualSize = ..(próxima explicación); 

*SizeOfRawData = .. (próxima explicación); 

*Characteristics = OxE00000E0; 

*PointerToRawData = pSection->PointerToRawData+pSection- 
>SizeOfRawData; 


La función PEAlign obtiene el primer parámetro redondeado al múltiplo más 
cercano del segundo parámetro. Queda definida de la siguiente manera: 


DWORD CPEcoderDlg::PEAlign (DWORD Num,DWORD AlignTo) 


( 


while (Num % AlignTo != 0) 
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( 

Num++5 
) 
return Num; 
) 


Se utilizará esta función para alinear la sección en memoria. En aras a la sencillez, 
olvídese que esta función habrá de emplearse en el cálculo de SizeOfRawData (con 
alineamiento de FileAlignment). Se añadirá esta función una vez que se haya 
calculado el valor correcto de SizeOfRawData. 


Para asegurar que el fichero permanecerá operativo, habrá que modificar ciertos 
valores de la estructura IMAGE NT HEADERS: aumentar SizeOfImage, 
SizeO0fCode y SizeO0fInitializedData según el tamaño de los datos nuevos, y 
aumentar el valor en uno de NumberOf Sections por haber añadido la nueva sección. 
El código resultante será: 


PImageNT->FileHeader.NumberO0fSections += 1; 
pImageNT->OptionalHeader.SizeOfImage += *SizeOfRawData; 
pImageNT->OptionalHeader.SizeOfCode += *SizeOfRawData; 
pImageNT->OptionalHeader.SizeOfInitializedData += 
*SizeOfRawData; 


Para añadir la nueva sección con éxito, sólo resta almacenar el contenido de la memoria 
en el fichero. Si el lector no supiera cómo llevar esto a cabo, podrá encontrar el código fuente 
completo y el codificador PE ya terminado con comentarios al final de este capítulo. 


Redirección de los datos 


Tras haber creado una nueva sección llega el momento ahora de definirle código y 
de dirigirle el flujo de datos. Para empezar, se incluirá código sin ningún objetivo en 
especial en la sección, por ejemplo un par de instrucciones NOP, y luego se sustituirá con 
el código de control real. Posteriormente se describirá cómo crear el código de control. 


Figura 7-8. La nueva sección incluida ya en el fichero 
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A la hora de redirigir las instrucciones procesadas por el fichero, constituye un paso 
esencial sustituir el valor Program Entry Point de la estructura 
IMAGE NT HEADERS con la RVA de los datos necesarios. Así se explica que tras haber 
procesado los datos pertinentes, sea necesario volver al código original para cerciorarse 
que también se procesa (suponiendo que deba ser procesado). Para ello y por el momento, 
bastará con la instrucción JMP. Se profundizará más en este asunto en las secciones 
posteriores del capítulo. 


Se muestra a continuación un esquema de la operación recién descrita: 


PE 


Program Entry Point Program Entry Point 


(original) (new) 


Added code 


Jump back 


Figura 7-9. Nuevo flujo del Program Entry Point 


Seguidamente se muestra el código para redirigir Program Entry Point, 
añadido mediante la función AddSection. Basta tan sólo con sustituir la RVA del 
Program Entry Point original con la RVA del comienzo de la sección nueva donde 
se ubicará el código, esto es, según el valor de VirtualAddress. 


pImageNT->OptionalHeader.AddressOfEntryPoint = 
*VirtualAddress; 


Inclusión de código en una sección nueva 


Tal vez la mejor solución para incluir código en una sección nueva del fichero 
consista en crear otra función en el codificador, en el sitio en el que se guardará el código 
de control del codificador y donde se definirán las variables globales necesarias para 
incluirlo. 
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Esta función puede denominarse, por ejemplo, AddedCode. Está diseñada para 
que siempre que se ejecute sólo defina las variables (por sencillez se utilizarán variables 
globales de doble palabra sin explicar cómo se definen) con los datos necesarios, sin que 
llegue a procesar el código de control del codificador. La invocación a esta función se 
realizará desde el siguiente sitio: 


AddedCode () ; // carga de variables globales 
DWORD FileSize = GetFileSize(File,NULL); 
DWORD Size = FileSize+CODE SIZE+0x1000 /*Buffer 
(FileAlignment...)*/; 
BYTE *pMem = new BYTE [Size]; // asignación de 
// memoria 


La definición de la función AddedCode: 


void _ stdcall AddedCode()  // convención para 
// invocar _ stdcall 


asm 
( // definición de valores en variables globales 
mov eax,offset CodeEnd 
sub eax, offset CodeStart 
mov CODE_SIZE,eax 
mov eax,offset CodeStart 
mov CODE _START,eax 
jmp CodeEnd // al ejecutar esta función no debe 
//  procesarse el código de control 


) 


/**x* Código de control para incluir en el fichero **x*/ 
CodeStart: 


nop 
nop 


) 


CodeEnd: ; 


) 


Como el lector ya habrá anticipado, se puede utilizar a continuación la variable 
global CODE SIZE (el tamaño real del código de control) a la hora de asignar la memoria 
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y calcular el valor real de SizeOfRawData y de VirtualSize para la sección nueva 
(véase la función AddSection): 


*SizeOfRawData = PEAlign(CODE_SIZE,pImageNT- 
>OptionalHeader.FileAlignment); 
*VirtualSize = CODE SIZE; 


La misma función empleada para crear la nueva sección, esto es, AddSection, 
añadirá el código en memoria. Su definición: 


memcpy ( (VOID*) (pMem+*PointerToRawData) , (VOID*) (CODE_STAR 
T) CODE_SIZE); 


Queda destacar el hecho de que en circunstancias normales la suma de 
SizeOfRawData y de VirtualSize de la última sección debería ser equivalente al 
tamaño total del fichero entero. Situación que no sucede siempre. Algunos ficheros no 
tienen que cumplir esta condición y aparentan ocupar más tamaño del que realmente 
tienen. Por ello, resulta preferible emplear la suma de SizeOfRawData y de 
VirtualSize (si fuera posible) en vez del tamaño total del fichero. Así se ahorrarán 
problemas. 


Bifurcaciones y variables 


Existen varias maneras de volver a los datos originales, o para ser precisos, al 
Program Entry Point original. Seguidamente se ejemplificará este paso con la 
opción más sencilla: mediante instrucciones JMP. Por supuesto, el código original podrá 
invocarse con la instrucción CALL desde el código de control y bifurcar a aquél de nuevo. 
El número de posibilidades es ilimitado. Ahora bien, recuérdese que, como aspectos 
críticos de la protección, toda la seguridad del codificador PE radica en el método de 
guardar y bifurcar al Program Entry Point original. Normalmente, el primer paso 
de un cracker consiste en buscar el Program Entry Point original para 
descodificarlo manualmente. Si además se cometiese algún error en la protección 
(incorrecta comprobación de puntos de corte, ausencia de comprobación de la integridad 
de los datos, no protegerse contra el volcado de datos, etc.), el cracker dispondrá de todos 
los recursos para poder descodificar el fichero manualmente. 


Resulta preciso almacenar el valor de la bifurcación al Program Entry Point 
original en algún sitio antes de sobrescribirlo con un valor nuevo. Aquí es donde las 
variables juegan su papel, o para ser más concretos, el espacio de almacenamiento que el 
código de control del codificador PE necesita para trabajar. Pronto se observará que el 
espacio de almacenamiento que el código de control necesita inmediatamente desde su 
arranque (a este grupo de variables se le denominará variables de inicialización) no 
constituye el único problema que ha de resolverse a este respecto. A medida que el código 
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de control se hace más complicado también será necesario más espacio de almacenamiento 
temporal al que acceder fácil y rápidamente. 


Como suele suceder, hay muchas formas de resolver estos problemas. Las variables 
de inicialización se pueden almacenar directamente en el código de control. Sin embargo, 
los valores así almacenados resulta fácilmente visibles y la seguridad, nula por tanto. El 
método más utilizado y bastante mejor para la inicialización y también para las variables 
temporales, consiste en reservar cierto espacio para ellas en el código de control (con 
frecuencia, donde éste finalice) y cargarlas desde ahí. Aunque existan muchos otros 
métodos de almacenamiento para las variables temporales, éste posiblemente resulte el 
menos complicado para poder luego acceder a ellas. 


Si bien desde el punto de vista de la seguridad resulte mejor almacenar las variables 
en distintos sitios, ha de considerarse que ello acarrea la necesidad de otro código de 
control que, de todos modos, resultará visible a un depurador. Por lo tanto, resulta 
preferible almacenar las variables en un solo sitio, cargarlas cómodamente desde ahí y 
centrarse en un buen mecanismo que las proteja, por ejemplo, codificándolas. Lo que 
debería aplicarse especialmente a la protección del valor del Program Entry Point 
original. 


El valor de ImageBase también resulta aquí esencial. El Program Entry 
Point es una RVA a la que debe sumarse el valor de ImageBase para obtener la VA 
real de la bifurcación. No puede almacenarse únicamente el valor final de la suma de estos 
dos valores puesto que el valor de ImageBase puede cambiar en caso de una asignación 
de memoria fallida, y así dicha suma sería incorrecta. Ese valor debe calcularse mientras el 
programa esté ejecutándose. 


Es cierto que esta afirmación no se puede aplicar en el caso de ficheros EXE, ya que 
no contienen reubicaciones y por tanto colapsarían si no realizasen la asignación de 
memoria en la dirección del valor de ImageBase. Ahora bien, existen muchos ficheros 
EXE que sí contienen reubicaciones (por ejemplo, los programas escritos en Delphi); 
también es importante en el caso de las librerías DLL. 


Por motivos pedagógicos en el siguiente ejemplo no se empleará ninguna 
codificación y ningún otro método de protección de variables adicional, ¡Que no se piense, 
sin embargo, en hacer lo mismo con un codificador PE real! 


Las variables se almacenarán al final del código de control; una variable global, 
VAR_STAT, marcará el principio de su posición y obtendrá sus valores como en los casos 
anteriores. 


void _ stdcall AddedCode () // convención para invocar 
// _ stdcall 
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( 


asm 
( // valores de las variables globales 

mov eax,offset CodeEnd 

sub eax,offset CodeStart 

mov CODE _SIZE,eax 

mov eax,offset CodeStart 

mov CODE START, eax 

mov eax,offset VariablesStart // posición de las 

// variables 
sub eax, offset CodeStart 
mov VAR_START,eax 


jmp CodeEnd // al invocar esta función el código 
//de control no debe procesarse 
) 


/***Código de control para incluir en el fichero**x*/ 
CodeStart: 
_ asm 


VariablesStart: 
[FRA HInitiation variables*t***x*x*x*x*/ 
NewEntryPointRVA: // RVA del nuevo Program Entry 
//Point 
_ emit O // se utilizan caracteres cero por 
// exigirlo la asignación de espacio, 
// serán sustituidos con sus valores 
// precisos 
_ emit 0 
_ emit 0 
_ emit O 


OrgEntryPointkRVA: //  RVA del Program Entry Point 
//original 
_ emit O 
_ emit O 
_emit 0 
_ emit 0 


/**Los valores de estas variables se obtendrán al 
ejecutarse el programa**/ 
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ImageBase: 
_ emit O 
_ emit O 
_ emit O 
_ emit O 
) 

CodeEnd: ; 
) 


Obsérvese que el valor de ImageBase ha de calcularse en el momento de ejecutar 
el programa. Para hallar su valor debe procederse de la siguiente manera: una vez guardada 
la RVA del nuevo Program Entry Point, calcúlese su VA, que podrá determinarse 
fácilmente a partir del código de control. El resultado será la ImageBase actual. 


Ahora que ya se dispone de espacio para las variables, podrán obtenerse sus 
valores. Para simplificar el almacenamiento de las variables de inicialización con sus 
respectivas direcciones, se utilizará un campo en cuyos ítems se ubicarán los valores 
de las variables en el mismo orden en el que se encuentran en el código de control (las 
variables temporales se situarán detrás puesto que se guardarán cuando el programa 
esté ejecutándose). Este campo se puede ampliar fácilmente para más variables; 
bastará con un mandato para almacenarlas en el código de control. 


A continuación se muestra el código referido: 


static DWORD VAR [x]; 


/*******EFunción AddSection+******/ 

*VirtualAddress = PEAlign (pSection- 
>VirtualAddress+pSection->Misc.VirtualSize,plmageNT- 
>OptionalHeader.SectionAlignment) ; 

*VirtualSize = CODE_SIZE; 

*SizeOfRawData = PEAlign(CODE_SIZE,pImageNT- 
>OptionalHeader.FileAlignment) ; 

*Characteristics = OxE00000E0; 

*PointerToRawData = pSection->PointerToRawData+pSection- 
>SizeO0fRawData; 


/¡*****x**Campo con las variables****x*x*x*/ 
VAR [0] = *VirtualAddress; 
VAR [1] = pImageNT->OptionalHeader.AddressOfEntryPoint; 


/***Inclusión de las variables en el código de control***/ 
memcpy ( (VOID*) (pMem+*PointerToRawData+VAR_START), (VOID*) 
VAR, sizeof VAR); 


202 CRACKING SIN SECRETOS ORA-MA 


El lector podrá, por supuesto, elegir un procedimiento distinto para almacenar las 
variables. 


Otro asunto por resolver es el de los métodos de acceso a las variables del código de 
control. El código de control que se muestra a continuación responde a todas estas 
cuestiones: 


push ecx 
push edx 
push esi 
push edi 
push ebp 


call CallMe 


CallMe: 


pop ebp 
sub ebp, offset CallMe 


mov ebx,offset CodeStart 
add ebx, ebp //  EBX = VA del nuevo Program Entry 
//Point 
sub ebx, [ebp+NewEntryPointRVA] //  EBX = ImageBase 
mov [ebp+ImageBase] , ebx // ¿guardando el valor de 
// ImageBase value en una 

// variable 
mov eax, [ebp+0rgEntryPointRVA] //  EAX = RVA del 

// Program Entry Point original 
add eax,ebx // EAX = EAX+EBX = VA del Program Entry 

// Point original 

pop ebp 
pop edi 
pop esi 
pop edx 
pop ecx 
pop ebx 
jmp eax  // bifurcación a los datos originales 


El primer paso consiste en almacenar los registros específicos (aunque en este punto 
parezca innecesario guardar ciertos registros, sí que serán de utilidad en el futuro). 
Seguidamente, la instrucción CALL invoca la instrucción siguiente. Puesto que CALL 
guarda la dirección de la próxima instrucción en una pila (para poder devolver el control 
fácilmente), la siguiente instrucción POP EBP almacenará su propia dirección en el 
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registro EBP. Ahora bien, la próxima instrucción, SUB EBP con desplazamiento CallMe, 
deberá contener siempre cero por estar obteniendo dos valores equivalentes. ¿Debe ser así? 
Dependerá de lo que se haga con el código. Si se ejecutara tal cual, el resultado será cero. 
Pero si se añadiera a otro fichero, se copiará al código del programa ya traducido y así el 
valor de desplazamiento CallMe será sustituido por un valor numérico con la dirección en 
el fichero fuente. Los valores obtenidos de esta manera serán, por tanto, distintos y la 
diferencia resultante, cierto valor de desplazamiento de la posición de las variables entre el 
fichero fuente y el de destino. El valor de la posición de la variable en el fichero fuente 
original se sumará a esta diferencia, el resultado constituirá la dirección real de la variable. 
En pocas palabras: es necesario acordarse de que la posición de los datos no es la misma 
en el fichero fuente de donde se copia el código de control (codificador PE) que en el 
fichero de destino. Es preciso primero calcular este desplazamiento y emplearlo para hallar 
la posición correcta de las variables. 


Tras haber calculado el valor de ImageBase y cargado la variable 
OrgEntryPointRVA, ambos valores se suman, su resultado será la VA real del 
Program Entry Point original. El resultado se guarda en el registro EAX, los demás 
registros se redefinen. Resulta innecesario a estas alturas explicar la misión de la 
instrucción JMP EAX (la bifurcación deseada para volver a los datos originales). 


Conviene recordar de nuevo que no debe presentarse el valor inicial del Program 
Entry Point volviendo simplemente a los datos originales: debe codificarse antes, O 
quizás al lector se le ocurra alguna idea más original. El lector que haya leído el libro 
desde su principio, ya conoce varios métodos para mover el programa de un sitio a otro 
disimuladamente —SEH, SMC (ningún buen algoritmo de protección puede prescindir de 
estas técnicas), etc.—. 


Funciones importadas 


El código insertado en un programa normalmente emplea cierto número de 
funciones API. Ahora bien, no se debe confiar en que el código del programa también 
utilice estas mismas funciones y que asimismo queden disponibles para el código de 
control. Existen varias maneras de resolver este problema. Se pueden añadir las funciones 
a la tabla de importaciones (o, con más precisión, desplazarlas a un sitio diferente en el 
fichero con suficiente espacio), o bien añadirlas a una tabla de importaciones propia e 
importarlas manualmente, lo que las cargará de la tabla original en el código de control. 


Aunque la primera opción sea algo más sencilla, su aplicación para la antipiratería 
resulta imposible. Ya se ha reincidido varias veces en lo provechoso que resulta la información 
sobre funciones importadas para un cracker potencial. Es muchísimo mejor añadir una tabla de 
importaciones nueva al fichero. Ahora bien, esta tabla no deberá contener (por los motivos de 
seguridad anteriormente mencionados) la lista de todas las funciones API utilizadas por el 
código de control. Sólo contendrá dos funciones API —GetProcAddress y 
LoadLibraryA— de la librería kernel32.dll, útiles para localizar una dirección de cualquier 
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función API (en otras palabras: para invocar cualquier función APD). El código de control 
invocará estas direcciones en vez de recurrir directamente al nombre de las funciones. 


Al añadir la tabla nueva de importaciones al fichero y modificar los valores 
pertinentes para asegurar que señalan a la tabla de importaciones nueva, el cargador PE no 
procesará, por supuesto, la tabla original. Será el código del programa, que quedará 
incorporado al código de control, quien tenga que resolver este problema. A este código 
del programa se le identificará como importador de funciones. 


A pesar de estas consideraciones, la tabla original de importaciones sigue teniendo 
su importancia. De no modificarse, supondría un agujero en la seguridad. 


Entre las funciones más importantes de un codificador PE figuran las de procesar 
correctamente las importaciones y proteger la tabla original de importaciones. Téngase en 
cuenta que un cracker potencial nunca podrá ejecutar un fichero descodificado 
manualmente sin la tabla de importaciones original: su protección constituye un aspecto de 
la seguridad que debe asumirse con seriedad. Si la tabla original de importaciones quedase 
sin modificar, el posible cracker, tras descodificar el fichero, no necesitará ni reconstruirlo 
siquiera. 


Un método más inteligente de codificación solventaría este problema (si 
sencillamente toda la tabla se codifica para luego descodificarla, cualquier cracker podría 
guardarla ya descodificada). Otra alternativa consiste en desplazar partes importantes de la 
tabla a ubicaciones diferentes y procesarlas desde allí. Al cracker le costará más reconstruir 
la tabla original y, lo que es más importante aún, con este método se obstaculiza 
significativamente el depurado al no resultar visibles los nombres de las funciones. 


Toda atención resulta escasa a la hora de procesar y proteger la tabla original de 
importaciones, ninguna solución llegará a ser demasiado radical en estos casos. No debe 
olvidarse que los crackers están acostumbrados a desenvolverse en situaciones extremas. 


No se concederá más atención a la protección de la tabla original de importaciones, 
El objetivo primordial de este capítulo consiste en mostrar aplicaciones de la tabla nueva 
de importaciones y de la importación de funciones para asegurar que el fichero permanece 
operativo. Queda al arbitrio del lector elegir alguna de las varias soluciones para proteger 
la tabla de importaciones que hasta aquí se han ofrecido. 


CREACIÓN DE UNA TABLA DE IMPORTACIONES 


En primer lugar se estudiará cómo crear una tabla nueva de importaciones. Con tal 
propósito, se definirá una función denominada AssemblelIT, cuyo objetivo será crear la 
tabla de importaciones tras el código añadido. Al añadir aquí progresivamente más datos, 
será necesario introducir otra variable global denominada OTHER _SIZE, que albergará los 
tamaños de estos datos —y que por el momento— será igual al tamaño de la tabla de 
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importaciones (la variable irá aumentando gradualmente). Nunca se olvide añadir este 
valor a la hora de asignar memoria. 


Llega el momento de centrarse en la construcción de la tabla de importaciones. 
Nuestra tabla importará sólo de una única librería —kernel32.dll, por lo que contendrá dos 
estructuras IMAGE IMPORT DESCRIPTOR— una con la librería y otra finalizando con 
caracteres nulos. También incluirá dos estructuras IMAGE THUNK_DATA y una de 
terminación, más dos estructuras IMAGE IMPORT BY NAME por tener que importar dos 
funciones API GetProcaddress y LoadLibraryA. Todo ello supone, junto con los 
nombres de las funciones API y la librería DLL, 61h=97 bytes en total (no deben olvidarse 
los caracteres nulos de finalización detrás cada secuencia de caracteres). 


A continuación se muestra un ejemplo de este tipo de tabla (comienza en la posición 
de memoria 00405000): 


00405000: 00 00 00 00 DO 00 00 Do 00 00 00 00 54 50 00 00 

00405010: 28 50 00 00 00 00 09 00 00 00 00 00 00 00 00 00 (e 

00405020: 00 00 00 00 00 00 00 00 34 50 00 00 43 50 00 00 4p CP 
00405030: 00 00 00 00 00 00 4C 6F 61 64 4C 69 62 72 61 72 

LoadLibr: 
00405040: 79 41 00 00 00 47 65 74 50 72 6F 63 41 64 64 72 yA GetProcAddr 
00405050: 65 73 73 00 6B 65 72 6E 65 6€ 33 32 2E 64 60 60 ess kernel32.d11 
00405060: 00 


Las primeras cinco dobles palabras constituyen la estructura 
IMAGE IMPORT DESCRIPTOR, relativa a la librería DLL desde la que se realiza la 
importación. No debe darse ningún valor a las tres primeras dobles palabras de la estructura, 
esto es, OriginalFirstThunk, TimeDateStamp, y ForwarderChain. Sus valores 
serán nulos. Sin embargo, sí que habrá que definir valores a los ítems Name (un puntero RVA a 
los nombres de la librería) y FirstThunk (puntero RVA a la estructura 
IMAGE THUNK_DATA). Le siguen la estructura final IMAGE IMPORT DESCRIPTOR con 
caracteres nulos y tres estructuras IMAGE THUNK_DATA. Las primeras dos estructuras 
contienen un puntero RVA a las estructuras IMAGE IMPORT BY NAME de las funciones 
LoadLibraryA y GetProcAddress. La tercera es una estructura final conteniendo, de nuevo, 
caracteres nulos. Luego quedan dos estructuras IMAGE IMPORT BY NAME de estas 
funciones; el ítem Hint (primeros dos bytes) no ha de cobrar ningún valor. Debe colocarse un 
carácter nulo final tras los nombres de las funciones importadas. En último lugar figura el 
nombre de la librería con un carácter nulo final. 


Así quedaría la función AssembleIT finalmente: 


void CPEcoderDlg::AssembleIT (BYTE *pMem, DWORD 
NewSectionRAW, DWORD NewSecti-onVA, PIMAGE _NT_HEADERS 
pImagenNT) 

[ 

DWORD *Name = new DWORD; 

DWORD *FirstThunk = new DWORD; 

DWORD *ThunkLoadLibrary = new DWORD; 


TP 
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DWORD *ThunkGetProcAddress = new DWORD; 
NewSectionRAW += CODE SIZE; // inserción de la 
// tabla tras el código de control 
*Name = NewSectionVA+2*sizeof 
IMAGE_IMPORT DESCRIPTOR+3*sizeof 
IMAGE THUNK_DATA+12+1+14+1+2*sizeof WORD; 
// Name = Puntero RVA al nombre de la librería 
*FirstThunk = NewSectionVA+2*sizeof 
IMAGE IMPORT DESCRIPTOR; 
//  FirstThunk = punter 
// RVA a la estructura 
1/ IMAGE _THUNK_DATA 
memcpy ( (VOID*) (pMem+NewSectionRAW+12) Name, sizeof 
DWORD) ; // Name 


memcpy ( (VOID*) (pMem+NewSectionRAW+16), FirstThunk, 
sizeof DWORD); //  FirstThunk 


*ThunkLoadLibrary = NewSectionVA+2*sizeof 
IMAGE_IMPORT _DESCRIPTOR+3*sizeof IMAGE _THUNK_DATA; 
//  ThunkLoadLibrary = valor de la 
//estructura IMAGE _THUNK_DATA // 
para la función LoadLibraryA 


*ThunkGetProcAddress = NewSectionVA+2*sizeof 
IMAGE IMPORT _DESCRIPTOR+3*sizeof 
IMAGE THUNK_DATA+sizeof WORD+12+1; 


memcpy ( (VOID*) (pMem+NewSect ¡onRAW+2*sizeof 
IMAGE IMPORT DESCRIPTOR), (VOID*) ThunkLoadLibrary, sizeo 
f IMAGE THUNK_DATA); // ThunkLoadLibrary 


memcpy ( (VOID*) (pMem+NewSectionRAW+2*sizeof 

IMAGE _IMPORT_DESCRIPTOR+sizeof 

IMAGE THUNK_DATA), (VOID*) ThunkGetProcAddress,sizeof 

IMAGE THUNK_DATA) ; 
//  ThunkGetProcAddress 
DWORD Address = NewSectionRAW+2*sizeof 

IMAGE IMPORT _DESCRIPTOR+3*sizeof 

IMAGE THUNK_DATA+sizeof WORD; 
pMem [Address] = 0x4C; // L 
pMem [Address +1] = 0x6F; 1/ 
pMem [Address +2] = 0x61; 1/ 
pMem [Address +3] = 0x64; 1/ 
PpMem [Address +4] 0x4C; Ay 
PpMem [Address +5] 0x69; 1/ 
pMem [Address +6] = 0x62; KA 


COP paso 
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5h 


pMem [Address +7] = 0x72;  // 
pMem [Address +8] 0x61; 1/ 
pMem [Address +9] = 0x72; 1/ 
pMem [Address +10] = 0x79; // 
pMem [Address +11] = 0x41; // 


PDRRDR 


Address = NewSectionRAW+2*sizeof 
IMAGE IMPORT DESCRIPTOR+3*sizeof 
IMAGE 'THUNK_DATA+2*sizeof WORD+12+1; 

PMem [Address] = 0x47; 1 

pMem [Address+1] = 0x65; 1/ 

pMem [Address+2] = 0x74; YI 

pMem [Address+3] Ox50; 1/ 

PpMem [Address+4] = 0x72; PR 

pMem [Address+5] = 0x6F; 1/ 

pMem [Address+6] = 0x63; 1/ 

PMem [Address+7] = 0x41; 4? 

pMem [Address+8] = 0x64; 07) 

PMem [Address+9] = 0x64; 1/ 


VOUORAOAAy:OAORmuUrOoa 


pMem [Address+10] = 0x72; // 
pMem [Address+11] = 0x65; // 
pMem [Address+12] = 0x73; // 
pMem [Address+13] = 0x73; // 


Address =NewSectionRAW+2*sizeof 
IMAGE IMPORT _DESCRIPTOR+3*s izeof 
IMAGE THUNK_DATA+2 *sizeof WORD+12+1+14+1; 


pMem [Address] = 0Ox6B; Il E 
pMem [Address+1] = 0x65; /1/ e 
pMem [Address+2] = 0x72; E 
pMem [Address+3] = 0x6E; // n 
pMem [Address+4] = 0x65; /1/ e 
pMem [Address+5] = 0x6C; E Y 
pMem [Address+6] = 0x33; Je 3 
pMem [Address+7] = 0x32; 11 2 
pMem [Address+8] = 0x2E; HL 5 
pMem [Address+9] = 0x64; 11 a 
pMem [Address+10] = 0x6C; // 1 
PMem [Address+11] = 0x6C; // 1 


delete ThunkGetProcAddress; 
delete ThunkLoadLibrary; 
delete FirstThunk; 

delete Name; 
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pMem es el puntero a la memoria asignada, NewSectionRaw es un 
PointerToRawData a la nueva sección añadida, NewSectionVA es su 
VirtualAddress y pImageNT, un puntero a la estructura IMAGE _NT_HEADERS. 


Con este ejemplo, el lector puede, por supuesto, sustituir los cálculos de las 
posiciones de las partes individuales de las estructuras con los valores ya definidos por 
saber ya el tamaño exacto de las estructuras individuales y sus partes. Ahora bien, de esa 
manera no queda ilustrada la forma de realizar los cálculos individuales. Se emplea a 
continuación el primer valor calculado, Name (puntero RVA al nombre de la librería) 
como ejemplo: 


*Name = NewSectionVA+2*tamaño de 

IMAGE IMPORT _DESCRIPTOR+3*tamaño de 

IMAGE _THUNK_DATA+12+1+14+1+4+2* tamaño de WORD; 

2*tamaño de IMAGE IMPORT DESCRIPTOR = 2*5*DWORD = 40 bytes 
3*tamaño de IMAGE THUNK_DATA = 3*DWORD = 12 bytes 

12+1 - secuencia LoadLibraryA + caracter nulo de terminación 
- ítem Nombre de la primera estructura IMAGE _IMPORT_BY NAME 
14+1 - secuencia GetProcAddress + caracter nulo de 
terminación - ítem Nombre de la segunda estructura 

IMAGE IMPORT BY NAME 

2*tamaño de WORD = 2*2 bytes = 4 bytes - tamaño de los 
valores de Hint para ambas estructuras IMAGE IMPORT BY NAME 


84 bytes en total. Por lo tanto, el cálculo del valor de Name puede también 
escribirse de la manera siguiente: 


*Name =NewSectionVA+84; 
PROCESO DE UNA TABLA DE IMPORTACIONES ORIGINAL 


Tras haber creado con éxito una tabla nueva de importaciones, se prestará atención 
al importador de funciones, quien se encargará de que se procesen las funciones de la tabla 
original de importaciones. 


La clave de un importador (y de todo código que necesite cualquier función API en el 
futuro) radica en determinar las direcciones de dos funciones API —GetProcAddress y 
LoadLibraryA— contenidas en la tabla nueva de importaciones. Al procesar las 
importaciones, el cargador PE sobrescribirá los valores FirstThunk en nuestra tabla de 
importaciones y los sustituirá con las direcciones correctas de estas funciones API. Bastará con 
almacenar estos valores en alguna variable para que puedan luego emplearse. A continuación se 
muestra el código: 
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mov ebx, [ebp+ImageBase] // EBX = ImageBase 
mov edx, [ebx+3Ch] 
add edx, [ebp+ImageBase] //  EDX señala a 


// IMAGE NT_HEADERS 
add edx, 80h 
mov edx, [edx] //  EDX = Tabla de importaciones RVA 
add edx, [ebp+ImageBase] //  EDX = ImageBase+ Tabla de 
// importaciones RVA = IT VA 
add edx,16 // desplazamiento al último ítem de la 
// estructura IID - esto es, FirstThunk 
mov ecx,dword ptr [edx] //  ECX = FirstThunk 
add ecx, [ebp+ImageBase] //  ECX señala a la primera 
// estructura IMAGE THUNK_DATA 
mov edx, [ecx] //  EDX = dirección de la función 
// LoadLibraryA 
mov [ebp+ LoadLibrary],edx  // «se guarda _LoadLibrary 


add ecx,4 // desplazamiento a la segunda estructura 
// IMAGE THUNK_DATA 
mov edx, [ecx] //  EDX = dirección de la función 
// GetProcAddress 
mov [ebp+ GetProcAddress],edx  // se guarda 
// _GetProcAddress 


Antes el código del importador carga la tabla original de importaciones y su primera 
estructura IMAGE IMPORT DESCRIPTOR. 


// Por su nombre y comentarios, sobra describir las dos 
nuevas variables introducidas 
mov edx, [ebp+0rgIT] //  EDX = RVA de la tabla 

// original de importaciones 
add edx, [ebp+ImageBase] //  EDX = VA de IT 
mov eax, [edx] //  EAX = OriginalFirstThunk 
add eax, [ebp+ImageBasel //  ¿guárdense siempre las Vas 
// para facilitar su manejo 
mov [ebp+OrgFirstThunk] ,eax // se guarda 
// OriginalFirstThunk 
add edx,12 // desplazamiento tras OrgFirstThunk, 

//  TimeDateStamp y ForwarderChain 

mov eax, [edx] //  EAX = Name 
add eax, [ebp+ImageBase 
mov [ebp+Namel] ,eax // se guarda VA de Name 
add edx,4 
mov eax, [edx] //.  EAX = FirstThunk 
add eax, [ebp+ImageBase] 
mov [ebp+FirstThunk],eax // se guarda VA de FirstThunk 
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add edx,4 
mov [ebp+Buffer] ,edx // se guarda un puntero a la 
// próxima estructura IID 


El importador consistirá en un par de bucles. El principal se encargará de procesar 
todas las estructuras IMAGE IMPORT DESCRIPTOR y, por ello, de todas las librerías 
importadas desde el programa. El bucle finaliza en cuanto alcance la última estructura 
IMAGE_IMPORT_DESCRIPTOR, cuyo contenido consiste en una secuencia de ceros. Si 
todo marcha conforme a las expectativas, la RVA FirstThunk será equivalente a cero 
únicamente en la última estructura (lo que no tiene necesariamente que aplicarse a las otras 
variables de la estructura). 


Con objeto de facilitar el manejo de las variables, se añade el valor de ImageBase 
(traducción de RVA a VA). Ello obliga necesariamente a comprobar su equivalencia con 
el valor de ImageBase y no con cero. 


MainITLoop: 
mov ecx, [ebp+ImageBase] 
cmp [ebp+FirstThunk],ecx  // ¿VA de FirstThunk = 
// ImageBase? 
jz MainITEnd // en caso afirmativo, se habrán 
// procesado todas las librerías 


Se carga en el bucle principal la librería pertinente a partir de la estrúctura 
IMAGE_IMPORT DESCRIPTOR mediante la función API LoadLibraryA. Así se 
llegará a calcular la ImageBase de la librería. 


mov ebx, [ebp+Name1] 

push ebx // nombre de la librería 

mov eax, [ebp+_LoadLibrary] 

call eax  // CALL LoadLibraryA 

// test eax,eax 

//  jz Error 

mov ebx, eax //  EBX = ImageBase de la librería 


A continuación se utiliza el valor Original1FirstThunk para hallar la posición 
de estructuras IMAGE _THUNK_DATA de la librería correspondiente (almacenada en la 
variable OrgThunkData). Si OriginalFirstThunk fuera cero, se utilizará en su 
lugar FirstThunk. 
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mov ecx, [ebp+ImageBase] 
cmp [ebp+OrgFirstThunk] ,ecx // ¿VA de OrgFirstThunk 
// = ImageBase? 

jnz Nothing  // ¿RVA de OrgFirstThunk = 0? 
mov eax, [ebp+FirstThunk] // en caso afirmativo, 

// colocar el valor 

// FirstThunk en OrgFirstThunk 
mov [ebp+0rgFirstThunk] ,eax 
Nothing: 
mov ecx, [ebp+0rgFirstThunk] 
mov eax, [ecx] 
mov [ebp+OrgThunkData] ,eax // obtención de 
// IMAGE THUNK_DATA 


Se emplea un bucle anidado para calcular las direcciones de todas las funciones que 
librería concreta importa en el programa (mediante la función API 


GetProcAddress), aquéllas sustituirán las estructuras IMAGE _THUNK_DATA según la 
librería correspondiente. Este bucle se repetirá hasta dar con la última estructura 
IMAGE _THUNK_DATA con ceros. 


Al principio del bucle se comprueba si la importación es ordinal: 


SecondITLOOp: 
cmp [ebp+OrgThunkData] ,0 
jz OrgThunkJMP // ¿IMAGE THUNK_DATA = 0? 
mov eax, [ebp+0OrgThunkDatal 
and eax, IMAGE ORDINAL FLAG32 
cmp eax, 0 //. ¿importación ordinal? 
jnz Ordinal 


En cuanto la importación no sea ordinal, se cargará el nombre de la función 


importada desde la estructura IMAGE_IMPORT_BY_ NAME, la dirección de esta función 
en la librería se calculará mediante la función API GetProcAddress. 


mov ecx, [ebp+0rgThunkDatal 

mov edx, [ebp+ImageBase] 

add ecx, 2 // saltar ítem Hint 

add ecx, edx 

mov edi,ecx // EDI señala al nombre de la función 
push edi 

push ebx // EBX = ImageBase de la librería 
mov eax, [ebp+ GetProcAddress] 

call eax // CALL GetProcAddress 

// test eax,eax 

//  jz Error 

jmp Jump 
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Si la importación fuera ordinal, la constante IMAGE ORDINAL FLAG32 
(F80000000h) se deducirá a partir de la variable OrgThunkData; y la dirección de esta 
función en la librería, mediante la función API GetProcAddress. 


Ordinal : 
mov eax, [ebp+0rgThunkData] 
sub eax,80000000h // hallando la constante 
push eax 
push ebx 
mov eax, [ebp+_GetProcAddress] 
call eax // CALL GetProcAddress 
// test eax,eax 
// jz Error 


Ya procede realizar la función principal de todo el importador, esto es, el mismo 
procedimiento que el cargador PE empleará al procesar las funciones importadas. Los 
valores de las estructuras IMAGE THUNK_DATA quedarán sobrescritos con las 
direcciones de las funciones calculadas. 


Jump : 
mov esi, [ebp+FirstThunk] 
mov dword ptr [esil,eax //  sobrescribir 


Y de aquí, a otra función importada: 


mov ecx, [ebp+0rgFirstThunk] // carga de los valores 
// originales 
mov edx, [ebp+FirstThunk] 
add ecx,4 // desplazamiento para calcular los 
// valores de FirstThunk y OrgFirstThunk 
// siguientes 
add edx,4 
mov [ebp+OrgFirstThunk] ,ecx // guardando 
mov [ebp+FirstThunk] ,edx 
mov eax, [ecx] // cálculo del Nuevo valor de 
// OrgThunkData 
mov [ebp+0OrgThunkData] ,eax // esto es, contenido de 
//la estructura IMAGE THUNK_DATA 
jmp SecondITLoop // proceso de otra función importada 


Tras haber procesado las funciones individuales de la librería pertinente, puede 
procesarse otra librería: 
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OrgThunkJMP : 
mov edx, [ebp+Buffer] // Carga del puntero a la 
// estructura IID siguiente 
mov eax, [edx] //  EAX contiene el primer ítem de la 
// estructura, esto es, OriginalFirstThunk 
add eax, [ebp+ImageBase] //  EAX = VA de 
// OriginalFirstThunk 
mov [ebp+OrgFirstThunk],eax  // guardando VA de 
// OriginalFirstThunk 
add edx,12 // desplazamiento al ítem Name 
mov eax, [edx] 
add eax, [ebp+ImageBasel 
mov [ebp+Namel],eax  // guardando VA de Name 
add edx,4 // desplazamiento a FirstThunk 
mov eax, [edx] 
add eax, [ebp+ImageBasel 
mov [ebp+FirstThunk],eax  // guardando VA de 
// FirstThunk 
add edx,4 // desplazamiento tras FirstThunk 
mov [ebp+Buffer] ,edx // se guarda el puntero a IID 
jmp MainITLoop  // librería siguiente 


MainITEnd: 


Si se prefiriera transferir parte de la tabla original de importaciones a un sitio 
diferente (no resultará necesario recordar la necesidad de sobrescribir los datos de la tabla 
original con valores cualesquiera), bastará con alterar el código de inicialización del 
importador para cerciorarse de que carga los datos en la posición correcta y no en la 
dirección de la tabla original. En este caso, recuérdese asignar memoria suficiente para los 
ítems OriginalFirstThunk, Name y FirstThunk de todas las estructuras 
IMAGE IMPORT DESCRIPTOR de la tabla original que se transfieran. Si bien se puede 
reorganizar más aún la tabla y no sólo las estructuras IMAGE IMPORT DESCRIPTOR, 
apenas aportará efecto apreciable a la seguridad, con lo que sólo generará más trabajo 
innecesariamente. 


USO DE UNA FUNCIÓN IMPORTADA 


Por último, se ha añadido un ejemplo de función API (distinta a las funciones 
GetProcAddress y LoadLibraryA, incluidas directamente en la tabla de 
importaciones) en el código de control con objeto de añadirla al fichero. Si bien a la 
mayoría de los lectores les resulte obvio, un pequeño ejemplo podrá esclarecer aún más el 
caso. 
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Al conocer las direcciones de GetProcAddress y LoadLibraryA, se podrá 
localizar la dirección de cualquier otra función de otra librería e invocarla fácilmente, El 
procedimiento resulta prácticamente idéntico al del importador de funciones. 


En primer lugar habrá de guardarse en algún punto del código de control el nombre 
de la función que vaya a invocarse junto con el nombre de la librería que la contiene, En el 
ejemplo siguiente, tras las variables: 


Function: 

_ emit 0x4D  // M 
_ emit 0x65 // e 
__emit 0x73 If 8 
_ emit 0x73 //. 8 
_emit 0x61 // a 
__emit 0x67  // yg 
_emit 0x65  // e 
_emit 0x42 // B 
__emit 0x65  // e 
__emit 0x65  // e 
__emit 0x70 // p 
_ emit 0 // no se olvide el cero final 
User32: 

_emit 0x75 // u 

__emit 0x73 ll 8 

__emit 0x65 // e 

__emit 0x72  // 

_emit 0x33  // 3 

_emit 0x32 // 2 

__emit 0x2E // 
_emit 0x64  // 
_ emit 0x6C  // 
_ emit 0x6C  // 
_ emit 0 


PERA: 


Se puede apreciar que en este ejemplo se ha elegido una función API bien conocida 
—-MessageBeep. A continuación se indica el código que recoge esta función: 


mov eax, [ebp+_LoadLibrary] 

mov ecx, offset User32 

add ecx, ebp //  ECX = dirección del nombre de la 
// librería 

push ecx 

call eax // CALL LoadLibraryA 
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mov ebx,eax //  EBX = user32 ImageBase 


mov ecx, offset Function 

add ecx,ebp //ECX = dirección del nombre de la función 
mov eax, [ebp+_GetProcAddress] 

push ecx 

push ebx // user32 ImageBase 

call eax // CALL GetProcAddress 


push 40h  // MB_ICONASTERISK - tipo de sonido 
call eax  // CALL MessageBeep 


Uno de los típicos sonidos de Windows señalará la corrección del procedimiento. 


PROCESO TLS 


Muchos programas modernos utilizan TLS (almacenamiento local para hilos, en 
inglés “Thread Local Storage”). Se emplea en aplicaciones multihilo para almacenar datos 
de un hilo concreto. En el entorno multitarea, así se asegura, por ejemplo, que dos hilos no 
escriban en la misma variable global o que puedan intercambiar variables entre ellos, etc. 


Un programa que utilice TLS puede identificarse inmediatamente al ser distinto de 
cero el valor VirtualAddress de su estructura IMAGE DATA DIRECTORY [9] 
(ítem de la tabla TLS) o porque tenga una sección con el nombre .tls (u otro muy 
semejante). 


Al contemplar las direcciones de los ítems de TLS Table, se puede apreciar algo 
incorrecto: su valor señala fuera de la sección .tls. 


Esta disposición difiere ligeramente de la que se aplica, por ejemplo, a las funciones 
importadas o a las reubicaciones, donde las estructuras apuntadas por el ítem del campo 
DataDirectory se situaban en una sección especial. El ítem TLS Table apunta a la 
estructura IMAGE TLS DIRECTORY32, que contiene definiciones de algunos valores 
importantes en TLS y que quedan fuera de la sección .tls. 


typedef struct _IMAGE TLS DIRECTORY32 ( 
DWORD StartAddressOfRawData; 
DWORD EndAddressOfRawData; 
PDWORD Address0f Index; 
PIMAGE TLS CALLBACK *AddressOfCallBacks; 
DWORD Size0fZeroFill; 
DWORD Characteristics; 

) IMAGE TLS DIRECTORY32; 
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El ítem StartAddressOfRawData es la VA del comienzo de la sección .tls, 
EndAddressOfRawData es la suma de StartAddressOfRawData más 
VirtualSize, esto es, la VA del final de la sección sin alineamiento aplicando el valor 
SectionAl ignment. 


El valor SizeOfRawData de la sección .tls es, con frecuencia, cero, lo que indica 
que esa sección en particular sólo está definida en la tabla de secciones pero no existe en el 
fichero fisicamente: será el cargador PE quien la cree antes de la ejecución. Así se explica 
que los valores StartAddressOfRawData y EndAddressOfRawData sean en 
realidad VAs y no direcciones materiales. 


a Table eE E 


PTE a 000 0004700 00000400 ET 
D0000D84 00049000 DODODEDO 00048200 Co000040 
00000891 00044000 00000000 00049000 Co000000 
DDO01F1A 00048000 00002000 00049000 Co000040 
00000010 0004D000 D0000000 00048000 Co000000 
00000018 DOD4E000 00000200 00048000 50000040 
DO004F0O DOD4F000 00005000 00048200 50000040 
DODO3C00 00054000 00003000 00050200 50000040 


tight mouse click on a sectionmame for mote options... 


Figura 7-10. Los programas confeccionados con Delphi no sólo contienen la 
sección .tls 


Al trabajar con TLS resulta preciso distinguir entre la propia sección .tls, utilizada 
como espacio de almacenamiento para datos de hilos específicos, y la estructura definida 
por TLS. 


La sección .tls resulta aquí irrelevante. Sí es importante recordar que no puede 
codificarse esta sección, ni en el caso de una sección .bss ni en el de ninguna otra con valor 
cero en SizeOfRawData. Causaría un error (además, si el valor SizeOfRawData 
resultase ser cero, no quedaría nada que codificar). Esta sección no se procesará de ningún 
otro modo. 


Mucho más importante resulta la estructura IMAGE TLS DIRECTORY32. El que 
esta estructura no se almacene en la sección .tls sino en alguna otra (con frecuencia .rdata), 
puede causar muchos problemas. Esta estructura podría quedar codificada al codificar 
alguna otra, lo que provocaría un error en el formato del fichero. En definitiva, esta 
estructura debe copiarse a algún “sitio seguro” del fichero con la consiguiente 
modificación de  TLS Table (variable VirtualAddress de la estructura 
IMAGE _DATA DIRECTORY [9]). 


La función que procese TLS puede denominarse, por ejemplo, ProcessTLS. A 
continuación se muestra su definición: 
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void CPEcoderDlg::ProcessTLS (BYTE *pMem, DWORD 
VAddress,PIMAGE _NT_HEADERS pImageNT,DWORD FileSize,DWORD 


Offset) 

memcpy ( (VOID*) (pMem+FileSize+CODE_SIZE), (pMem+Offset), 
sizeof IMAGE TLS DIRECTORY32); // se copia la 
estructura IMAGE TLS DIRECTORY32 // a otro sitio 


pImageNT->OptionalHeader. DataDirectory 
[9] .VirtualAddress = VAddress+CODE_SIZE; 
// redirección 


) 


El parámetro pMem es el puntero a la memoria asignada, VAddress es la 
VirtualAddress de la nueva sección, FileSize representa el tamaño original del 
fichero, y, por último, O£ £set es la ubicación material de IMAGE _TLS DIRECTORY32 


en el fichero. 


Esta función copia el contenido de la estructura IMAGE_TLS_DIRECTORY32 tras el 
código incluido en la sección nueva (CODE SIZE) para redirigir la variable 
VirtualAddress de la estructura IMAGE DATA DIRECTORY [9], que contiene 
información sobre la ubicación y tamaño de la estructura IMAGE _TLS_DIRECTORY32, a la 


ubicación nueva. 


A esta función se la invocará al final de la función AddSection: 


if (pImageNT->OptionalHeader. DataDirectory 
[9] .VirtualAddress != 0) 


PIMAGE _SECTION_HEADER Section = 

ImageRvaToSection (pImagenNT, pMem, 
pImageNT->OptionalHeader.DataDirectory 

[9] .VirtualAddress) ; 

DWORD Offset = pImageNT->OptionalHeader.DataDirectory 
[9] .VirtualAddress - Section->VirtualAddress+Section- 
>PointerToRawData; 


ProcessTLS (pMem, *VirtualAddress,plmageNT, *PointerToRawDa 
ta,Offset); 


) 


Pueden localizarse los valores VirtualAddres y PointerToRawData de la 
sección donde se almacena la estructura IMAGE TLS DIRECTORY32 mediante la 
función ImageRvaToSection para así hallar su posición real en el fichero (y guardar 
la posición de la variable Offset). 


218 CRACKING SIN SECRETOS ORA-MA 


CODIFICACIÓN 


Elección del algoritmo de codificación 


El propósito principal de un codificador PE consiste, por supuesto, en codificar una 
sección específica del fichero. La elección del algoritmo de codificación y/o 
descodificación afectará significativamente no sólo la seguridad, sino también la velocidad 
y la calidad global del codificador PE. A continuación se examinan algunos de los 
algoritmos de codificación más conocidos. 


Algoritmos de codificación comunes 


En primer lugar, resulta necesario distinguir entre codificación simétrica y 
asimétrica. Aquí se aplicarán algoritmos de codificación que podrían considerarse 
simétricos, esto es, aquellos que utilizan la misma clave tanto para codificar como para 
descodificar. Los algoritmos asimétricos, por el contrario, emplean claves distintas para 
codificar y descodificar (por ejemplo, RSA). Una vez generada, la clave se divide en una 
parte pública y otra privada, y al conjunto denominado pareja de claves. 


Los algoritmos de codificación simétricos resultan significativamente más rápidos 
que los asimétricos y, por lo tanto, más indicados para los codificadores PE. 


Por otra parte, algunos algoritmos de codificación asimétricos, como es el caso de 
RSA, resultan críticos para la codificación de datos. Razón que justifica examinarlos con 
detalle al final del capítulo, tanto en su vertiente teórica como práctica, y de igual modo, el 
diseño de algoritmos para calcular sus claves de codificación y descodificación. 


Algunos de los algoritmos simétricos profesionales más conocidos se indican a 
continuación: 


IDEA 


Este algoritmo destaca especialmente por su velocidad de codificación (mucho más 
rápido que DES) empleando una longitud de la clave suficientemente larga (128 bits). 
Ascom-Tech es la propietaria de la patente en la mayoría de los países europeos y en 
EE.UU. 


BlowFish 


Bruce Schneir diseñó este rápido algoritmo con la máxima longitud de clave: 448 
bits. No está patentado, se pretende que sea de libre circulación, lo que le convierte en una 
opción excelente para muchos programadores. 
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CAST 


El nombre recoge las iniciales de sus autores: Carlisle Adamsem y Stafford 
Tavernsem. Aunque muy parecido a BlowFish, desgraciadamente este otro algoritmo no es 
gratis. 


DES 


Este estándar de cifrado, desarrollado por IBM, llegó a ser la norma estadounidense 
de codificación en 1977. La longitud de la clave de este algoritmo es tan sólo de 56 bits, 
claramente insuficiente en el presente: puede anularse mediante una ataque masivo 
utilizando, por ejemplo, el programa DES Cracker. 


3DES 


Resulta prácticamente idéntico al algoritmo DES, si bien cifra los datos tres veces. 
Duplica la longitud de la clave (112) pero su velocidad disminuye lógicamente en un 
tercio. 


AES 


Este algoritmo, vigente desde el 26/05/2002, vino a sustituir, como nuevo estándar 
del gobierno federal norteamericano, a DES. AES (Estándar de cifrado avanzado, en 
inglés, “Advanced Encryption Standard”) soporta los 256 bits como máxima longitud de 
clave, la duración estimada de su coeficiente de seguridad llega a los 20 años. En Internet 
puede encontrarse el código fuente de este algoritmo en diferentes lenguajes de 
programación. 


En lo que a la compresión respecta, el CD adjunto contiene (documentación y 
ejemplos incluidos) una de las mejores librerías de compresión existentes en la actualidad: 
aPLib. El único aspecto negativo de esta librería reside en su carácter comercial. Si se 
pretendiera distribuir software donde se hiciera uso de esta librería, debería antes quedar 
registrada. 


Si el lector deseara crear su propio algoritmo de compresión (en cuyo caso no debe 
olvidar consultar el epígrafe “Violación del código”), la sección de referencia contendrá un 
ejemplo de algoritmo de compresión escrito en C++. 


Por resultar más pedagógico trabajar con algoritmos de codificación no muy 
complejos, en los ejemplos siguientes la codificación se llevará a cabo mediante XOR, 
fácilmente sustituible por cualquier otro algoritmo de compresión. Internet ofrece una gran 
cantidad de algoritmos de compresión además de información sobre cómo crearlos. La 
operación lógica XOR (disyunción exclusiva) se comporta conforme se indica a 
continuación: 


220  CRACKING SIN SECRETOS CORA-MA 


AXORB=C 
CXORB=A 


Según se puede observar, dados dos valores, A y B por ejemplo, siendo A los datos 
que se van a cifrar y B, la clave de cifrado, relacionados mediante un operador XOR, los 
datos cifrados serán C. Relacionando entonces C con la clave de cifrado B mediante el 
operador XOR, se obtendrán los datos originales (desciftados). Por tanto, aplicando un 
simple XOR para cifrar los datos, no existirá diferencia alguna entre el proceso de 
codificación y descodificación. 


A continuación se muestra la tabla de verdad para el operador XOR: 


A B C=AXOR B 
1 1 0 
1 0 I 
0 1 1 
0 0 0 


En ensamblador: 
Por ejemplo: xor eax,2 <-- EAX = EAX XOR 2 


Los algoritmos de codificación basados en la operación lógica XOR normalmente 
emplean varias tablas con los valores codificados que van modificándose según la clave de 
cifrado. 


Violación del código 


Siempre que se elija un procedimiento para generar la clave de descifrado incorrecto 
o no se utilice ninguno en absoluto (entendiendo por tales aquellos que aplican algoritmos 
de “cifrado” basados en complejas operaciones matemáticas), se corre el riesgo de que 
alguien viole el código. 


El mejor método para generar la clave de descodificación es el basado en su 
dependencia del estado de protección de los elementos del código de control. No es 
infrecuente encontrar protecciones que realizan una comprobación de integridad 
(“checksum”, en inglés) con los datos y luego la emplean como clave de descodificación. 
Hay muchas otras alternativas, por supuesto, en última instancia dependerá de la 
creatividad del desarrollador. Ahora bien, en ningún caso debe guardarse la clave de 
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descodificación directamente en el código de control. Se corre el riesgo de crear un 
descodificador universal. 


Toda la teoría sobre la posible violación del código se basa en el hecho de que si el 
cracker no cuenta con toda la información necesaria (y que normalmente adquiere 
utilizando un depurador), no podrá ni siquiera intentar violar el código. A la hora de buscar 
esta información, intentará anular todos los elementos anti... (antidepuración, anti puntos 
de corte) del código de control. No parece muy lógico que el paso siguiente sea intentar 
violar el código de control ya que generaría trabajo extra. El cracker esperará hasta que el 
código de control realice para él todas las operaciones necesarias (descodificación 
incluida). 


Si los procedimientos aplicados en la codificación y el método de generación de la 
clave no resultan obvios sin estudiar el código de control, el diseño de éste adquirirá 
mucha más importancia que el algoritmo de codificación. 


La situación varía enormemente al crear un descodificador universal. Resulta mucho 
más fácil para un cracker escribir un programa que descodifique el fichero mediante una 
clave de decodificación fija en vez de escribir un programa que ejecute el fichero y guarde 
el contenido en memoria, donde el fichero se descodifica. Como normalmente se emplea 
ProcDump para esta operación, deberá dotarse al programa de defensas contra esta 
herramienta. Un algoritmo de descodificación debe programarse de tal manera que resulte 
muy difícil sino imposible crear un descodificador universal que descodifique el fichero 
externamente sin llegarlo a ejecutar realmente. Si a ello se le suma una buena protección 
frente a ProcDump (o herramientas semejantes) y frente a los métodos que ProcDump 
emplea (volcado, rastreo), la creación de un descodificador universal se convertirá en una 
tarea muy difícil. 


El anteriormente mencionado codificador PE, PE Shield, constituye un ejemplo 
perfecto. Este codificador representa un difícil rompecabezas para los crackers por emplear 
codificación polimórfica y una fuerte protección contra ProcDump y otros 
descodificadores genéricos. 


Los ataques masivos no constituyen tampoco una excepción. Algunas personas se 
molestan en buscar errores en el algoritmo de descodificación que les permita descodificar 
los datos mediante ataques masivos durante un tiempo razonable. Ya se puso antes como 
ejemplo el error en la rutina de descodificación de SafeDisc. RISC descubrió este error e 
incorporó un descodificador basado en un ataque masivo que puede utilizarse para 
descodificar el fichero protegido incluso sin disponer del CD original. 


Áreas codificadas y no codificadas 


Resultaría muy pueril pensar que la codificación indiscriminada de todas las 
secciones del fichero no causaría ningún error y que el fichero aún quedara plenamente 
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operativo. De hecho, sólo se pueden codificar aquellas secciones que contengan datos que 
no sean necesarios para la inicialización del cargador PE. La situación varía para cada 
sección: dependerá de quién realice el proceso (el cargador PE o el programa original), de 
la sección en sí, de los datos que contenga, de cómo se desee codificar los datos, qué parte, 
etc, 


A estas alturas, tras haber examinado los distintos problemas relacionados con el 
proceso y codificación de algunas secciones, el lector ya se habrá hecho una idea 
aproximada de esta problemática. A modo de resumen, se podrían señalar las conclusiones 
siguientes: 


Nunca se deben codificar secciones con un valor igual a cero en 
PointerToRawData (por ejemplo, secciones .bss). 


En el caso de ficheros EXE, la codificación y la consiguiente necesidad de procesar 
la sección con la tabla de exportaciones (generalmente .edata) representan un trabajo 
adicional innecesario. Los ficheros EXE normalmente no contienen tabla de exportaciones 
y si lo hacen, carece de utilidad para el potencial cracker. 


Aunque por la codificación de otras secciones, el programa original sea el 
encargado de procesar las reubicaciones (normalmente .reloc) para cerciorarse de que no 
se produce ningún error, también resulta, en la mayoría de las ocasiones, innecesario. Los 
ficheros EXE tampoco suelen incluirlas y si lo hacen, el posible cambio en la dirección de 
carga en la mayoría de ficheros de este tipo suele venir causado por algún error crítico. Ya 
se mencionó todo ello con anterioridad, al explicar el término ImageBase. 


Las librerías DLL sí deben procesar reubicaciones. En la parte de referencia del 
libro puede hallarse información suficiente a este respecto así como un algoritmo con 
dicho fin. Representa un pérdida de tiempo codificar las reubicaciones, carecen de utilidad 
para un posible cracker. 


En lo que atañe al TLS, las secciones con recursos (.rsrc...) también pueden 
codificarse y procesarse. Resulta más complicado, pero aumenta la seguridad (consúltese 
el CD adjunto si se desea más información sobre cómo llevarse a cabo). 


Ya quedó explicado cómo se codifican y procesan las funciones importadas. 
Aunque se hayan mencionado los elementos de seguridad correspondientes a la tabla 
original de importaciones, también se puede ubicar el importador de funciones tras el bucle 
de descodificación y codificar entonces la sección con la tabla original de importaciones de 
la misma manera que las demás secciones (por supuesto, dependerá de la protección 
elegida para la tabla de importaciones original). Así se procederá en el ejemplo posterior, 
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Hasta aquí lo que respecta a los codificadores PE. Los compresores PE les suele 
bastar con comprimir procurando procesar la mayor cantidad de datos posible para obtener 
los mejores resultados de compresión. 


Ejemplo de una codificación sencilla con un codificador PE 


A continuación se mostrará cómo incluir un algoritmo de codificación muy sencillo 
al codificador PE. Con objeto de no complicar la aplicación, se utilizará una clave de 
cifrado fija y un sencillo algoritmo XOR. Debe recordarse una vez más que este tipo de 
codificación resulta absolutamente inaceptable en un codificador PE y que si aquí se utiliza 
es sólo por motivos pedagógicos. 


La función de codificación es realmente elemental: 


void CPEcoderDlg::SimpleCrypt (BYTE *pInput,DWORD 1Size) 


[ 
for (DWORD 1lCount = 0; lCount < l1Size; lCount++, 
pInput++) 
*pInput %= OxAB;  // XOR 
) 


El primer parámetro de la función es un puntero a los datos que se van codificar, y 
el segundo, su tamaño. 


A continuación se crea la función (denominada CryptPE) que codifica todas las 
secciones pertinentes del fichero: 


void CPEcoderDlg::CryptPE(PIMAGE_NT_HEADERS 
pImageNT,BYTE *pMem) 


IMAGE _SECTION_HEADER *pSection = new 
IMAGE SECTION HEADER; 
DWORD SecNum = pImageNT->FileHeader.Number0fSections; 
// número de secciones 
DWORD AdrOfSecTable; 


for (DWORD i = 0 ¡i< SecNum; i++) 


Adr0fSecTable = (DWORD) pImageNT+ (sizeof 
IMAGE NT HEADERS) +i* (sizeof 
IMAGE SECTION HEADER) ; 
// puntero a la tabla de secciones 
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*pSection = 
RvaToSection (pImageNT,pMem, Adr0fSecTable) ; 


if (*(LPDWORD) pSection->Name != 0x77656E2E 
/*" new "*/ £E 
* (LPDWORD) pSection->Name ! 


0x7273722E /*".rsr 


"x/ Es 

* (LPDWORD) pSection->Name != 0x63727372 /*"rsrc 
"*/ Es 

* (LPDWORD) pSection->Name != 0x6C65722E /*”.rel 
"*) ES 

* (LPDWORD) pSection->Name != 0x6F6C6572 /*"relo 
"*/ 58% 

* (LPDWORD) pSection->Name != 0x6164652E /*”.eda 
"x/ ES 

* (LPDWORD) pSection->Name != 0x736C742E /*.tls*/ 
Ese 

pSection->PointerToRawData != 0 ££ pSection- 
>SizeOfRawData != 0) 


( 


DWORD Size = (pSection->Misc.VirtualSize 
<pSection->SizeOfRawData ? pSection- 
>Misc.VirtualSize :pSection- 
>SizeO0fRawData); 

// tamaño de los datos cifrados 

SimpleCrypt (pMem+pSection- 
>PointerToRawData, Size); 

) 
) 
delete pSection; 


) 


Durante la secuencia se decide qué secciones se codifican a partir de los cuatro 
primeros caracteres del nombre de la sección y de un valor distinto a cero en 
PointerToRawData y SizeOfRawData. 


El nombre de la sección suele reflejar sus características y la necesidad de codificar 
su contenido. Aunque este método no parezca muy profesional, sí cumple con su misión. 
La mejor solución exigiría comprobar su contenido (buscando estructuras importantes), y 
no el nombre de la sección para así poder elegir directamente las secciones que se vayan a 
codificar. 


No se codificarán secciones con nombres tales como .reloc (reubicación), .cadata 
(funciones exportadas), .tls, .rsrc, (recursos) ni, por supuesto, las recién incluidas con el 
nombre .new. Puede ignorarse la tabla original de importaciones puesto que el bucle de 
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descodificación se situará en el código de control, frente al importador de funciones, quien 
recibirá entonces los datos ya descodificados. 


Con objeto de evitar la codificación y descodificación del alineamiento de 
caracteres nulos en las secciones y evitar posibles problemas posteriormente, el tamaño de 
los datos codificados vendrá dado por el menor de los valores de VirtualSize y 
SizeOfRawData. 


Esto, en lo que atañe a la codificación de las secciones. Deberá modificarse el 
código de control para permitir la descodificación. Para ello, primero se modificará su 
comienzo (la variable SecNum albergará el número de secciones del fichero) para incluir 
la rutina de descodificación. El algoritmo de descodificación quedará ubicado en la 
posición siguiente: 


/*******Código de control para incluir en el fichero 
KKRAAAAS 
CodeStart: 
asm 


( 


push ebx 
push ecx 
push edx 
push esi 
push edi 
push ebp 


call CallMe 


CallMe: 

pop ebp 

sub ebp, offset CallMe 
mov ebx, offset CodeStart 


add ebx,ebp  // EBX =VA del nuevo Program Entry 
// Point 
sub ebx, [ebp+NewEntryPointRVA] //  EBX = ImageBase 
mov [ebp+ImageBase] ,ebx // se guarda el valor 
// ImageBase en una variable 


mov edx, [ebx+3Ch] 

add edx, [ebp+ImageBase] //  EDX señala a 
// IMAGE NT_HEADERS 

mov [ebp+Buffer] , edx 

add edx,6 

mov bx, [edx] 
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mov 
add 


mov 
add 


add 
mov 
add 
mov 


mov 


add 


mov 


mov 


mov 


add 
mov 


word ptr [ebp+SecNum] ,bx // SecNum = número de 
// secciones del fichero 
edx,7Ah 
edx, [edx] //  EDX = tabla de importaciones RVA 
edx, [ebp+ImageBase]l //  EDX = ImageBase+ tabla 
// de importaciones RVA 
edx,16 


ecx,dword ptr [edx] // ECX = FirstThunk 
ecx, [ebp+ImageBase] // ECX = ECX+ImageBase 
edx, [ecx] //  EDX = dirección de la función 
// LoadLibraryA 
[ebp+_LoadLibrary],edx  // guardando en 
// _LoadLibrary 


ecx,4 

edx, lecx] //  EDX = dirección de la función 
// GetProcAddress 

[ebp+ GetProcAddress],edx  // guardando a 


// _GetProcAddress 
eax, [ebp+EntryPoint] //  FEAX = RVA de Program 
// Entry Point original 
eax, [ebp+ImageBase] 
[ebp+OrgEP] , eax 


/*K****Descodificación******x*/ 


/*******Final del algoritmo de descodficación *****x*x*/ 


mov 


add 
mov 
add 


mov 


add 


mov 
add 
mov 
add 
mov 
add 


edx, [ebp+0rgIT] // EDX = RVA de la tabla de 
// importaciones original 
edx, [ebp+ImageBase] //  EDX = VA de IT 
eax, [edx] //  EAX =RVA de OriginalFirstThunk 
eax, [ebp+ImageBase] // se guardan Vas para 
// facilitar su manejo 
[ebp+0rgFirstThunk],eax  // se guarda 
// OriginalFirstThunk 
edx,12 // desplazamiento tras OrgFirstThunk, 
// TimeDateStamp una ForwarderString 
eax, ledx] //  EAX = Name 
eax, [ebp+ImageBase] 
[ebp+Name1] , eax // se guarda VA de Name 
edx,4 
eax, [edx] //  EAX = FirstThunk 
eax, [ebp+ImageBase] 
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mov [ebp+FirstThunk],eax  // se guarda VA de 
// FirstThunk 
add edx,4 
mov [ebp+Buffer] ,edx // se guarda el puntero a la 
// estructura IID por comodidad 


[RRA RMainITLoo0p*****x*x*/ 


Consideremos los elementos individuales del algoritmo de descodificación, no muy 
diferente del algoritmo de codificación, lo que ahorrará algunas explicaciones. Por emplear 
un XOR, el algoritmo de codificación y descodificación resultan idénticos. 


/*R*x*k**Decoding*****x*x*/ 
xOr ecx,ecx // ECX = 0 - contador de secciones 
// procesadas 
mov edi, [ebp+SecNum] 
mov eax, [ebp+Buffer] 
add eax,0F83n  // EAX apunta a la primera estructura 
// IMAGE SECTION_HEADER 


MainDecodeLoop: 
cmp di,cx // ¿se han procesado todas las secciones 
// del fichero? 
jz DecodingDone 
push edi 


/*kkk** ¿Debe descodificarse esta sección?****x*x*x*/ 
mov ebx, [eax] // Name 

cmp ebx, 77656E2Eh // new 
jz NoDecoding 

cmp ebx,7273722Eh  // .rsr 
jz NoDecoding 

cmp ebx,63727372h //  xrsre 
jz NoDecoding 

cmp ebx,6C65722Eh //  .rel 
jz NoDecoding 

cmp ebx,6F6C6572h  // relo 
jz NoDecoding 

cmp ebx,6164652Eh //  .eda 
jz NoDecoding 

cmp ebx,736C742Eh  // .tls 
jz NoDecoding 


add eax, 8 // Carga de información sobre la sección 
// a partir de la estructura IMAGE SECTION HEADER 
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mov edi, [eax] //  VirtualSize 

add eax,4 

mov ebx, [eax] //  VirtualAddress 
add eax,4 

mov edx, [eax] //.  SizeOfRawData 
add eax,4 

mov esi, [eax] //  PointerToRawData 


cmp esi,0O  // ¿PointerToRawData = 0 ? 
jz NoDecoding 

cmp edx, 0 //  ¿SizeOfRawData = 0 ? 

jz NoDecoding 


cmp edi,edx 
jnl TakeSizeOfRawData //  ¿VirtualSize < 
// SizeOfRawData ? 
mov edx,edi // en caso afirmativo, se tomará este 
// valor como el tamaño de los datos por 
// descodificar (véase algoritmo de 
// codificación) 
TakeSizeOfRawData: 
mov esi, [ebp+ImageBase] 
add ebx,esi //  EBX = VA de los datos por 
// descodificar 
call SimpleCrypt // rutina de descodificación 
jmp SectionDecoded  // sección descodificada, buscar 
// siguiente 


NoDecoding: 
add eax,14h  // sección no procesada, necesario 
// omitir su estructura 
// IMAGE SECTION HEADER para buscar otra 
// sección(2*ADD EAX, 14h) 


SectionDecoded: 
add eax, 14h // omitiendo los restantes ítems de la 
// estructura IMAGE SECTION HEADER 
Ime ex // aumentando el contador de secciones 
pop edi 
jmp MainDecodeLoop 


DecodingDone: 


Los mejores codificadores PE no descodifican las secciones una sola vez y de 
manera simultánea, así resulta mucho más difícil guardar sus contenidos en disco en 
formato descodificado. Debe tenerse esto tan en cuenta como el incluir el código de 
control del codificador PE. Así se evitará su desensamblado. 
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DISEÑO FINAL DE UN CODIFICADOR PE 


Se expone a continuación el código íntegro del codificador PE. Puede resultar útil 
para quienes tengan dudas sobre algunos de los pasos o no sepan cómo programar aquellas 
partes no descritas explícitamente. Para facilitar la lectura del código, los comentarios 
figuran al final de las partes principales. 


// PEcoderDlg.cpp : fichero con el código 
1/ 


Hfinclude "stdafx.h" 
Hinclude "PEcoder.h" 
Hinclude "PEcoderDlg.h" 
Hinclude "imagehlp.h" 


Hifdef _DEBUG 

define new DEBUG_NEW 

ttundef THIS FILE 

static char THIS FILE[] = _ FILE ; 
Hendif 


ARA RARA AAA AAA AAA AAA AAA AAA 
// CPEcoderDlg dialog 


CPEcoderDlg: :CPEcoderDlg (CWnd* pParent /*=NULL*/) 
CDialog (CPEcoderDlg::IDD, pParent) 


//((AFX_DATA INIT(CPEcoderDlg) 

// NOTA: ClassWizard incluirá aquí el miembro de 
// inicialización 

//))AFX_DATA_INIT 

m_hIcon = AfxGetApp () ->LoadIcon (IDR_MAINFRAME) ; 


) 


void CPEcoderDlg: :DoDataExchange (CDataExchange* pDX) 
( 
CDialog: :DoDataExchange (pDX) ; 
/ /((AFX_DATA MAP (CPEcoderDlg) 
// NOTA: ClassWizard añadirá aquí las llamadas a DDX y 
// DDV 
//)) AFX_DATA MAP 
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BEGIN_MESSAGE MAP (CPEcoderDlg, CDialog) 

/ / í (AFX_MSG_MAP (CPEcoderDlg) 
ON_WM_PAINT () 
ON_WM_QUERYDRAGICON () 
ON_BN_CLICKED(IDC_OK, OnO0k) 
//)AFX_MSG_MAP 

END_MESSAGE MAP () 


RARA RARA AAA AAA 


// manejadores de mensaje CPEcoderDlg 


BOOL CPEcoderDlg: :OnInitDialog () 


( 


CDialog::OnInitDialog(); 


SetIcon(m_hIcon, TRUE); // Definición de icono 
// grande 

SetIcon(m_hIcon, FALSE); // Definición de icono 
// pequeño 


// Añádase aquí código extra de inicialización 


return TRUE; // TRUE a no ser que se cambie el flujo 
// de control 


// Si en el cuadro de diálogo se incluye un botón de 
// minimización, será necesario añadir el código 

// siguiente para dibujar el icono. Con aplicaciones 
// MFC que utilicen el modelo documento/ver, la 

// infraestructura común se encarga de realizar esta 
// operación. 


void CPEcoderDlg: :OnPaint () 


if (IsIconic()) 


( 


CPaintDC dc (this); // contexto de dispositivo 
// para pintar 


SendMessage (WM_ICONERASEBKGND, (WPARAM) 
dc.GetSafeHdc (), 0); 


// Centrar icono en el rectángulo del cliente 
int cxIcon = GetSystemMetrics (SM_CXICON) ; 
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int cyIcon = GetSystemMetrics (SM_CYICON) ; 
CRect rect; 

GetClientRect ($rect); 

int x = (rect.Width() - cxIcon + 1) / 2; 

int y (rect.Height () - cyIcon + 1) / 2; 


// Dibujar icono 
dc.DrawIcon(x, y, m_hIcon); 


CDialog: :OnPaint () ; 


HCURSOR CPEcoderDlg: :OnQueryDraglIcon () 


( 


return (HCURSOR) m_hIcon; 


) 


DWORD CODE SIZE = 0; 

DWORD CODE_START = 0; 

DWORD VAR_START = 0; 

DWORD OTHER_SIZE = sizeof IMAGE TLS DIRECTORY32 + 0x61; 


static DWORD VAR[3]; 


void _ stdcall AddedCode () 


mov eax, offset CodeEnd 

sub eax,offset CodeStart 

mov CODE_SIZE,eax 

mov eax, offset CodeStart 

mov CODE START, eax 

mov eax,ofíset VariablesStart 
sub eax,offset CodeStart 

mov VAR_START,eax 


jmp CodeEnd 


/****Código de control para incluir en el fichero****/ 
CodeStart: 
asm 


T 
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CallMe: 


push ebx 
push ecx 
push edx 
push esi 
push edi 
push ebp 


call 


pop 
sub 


mov 
add 
sub 
mov 


mov 
add 
mov 
add 
mov 
mov 
add 
mov 
add 


add 
mov 
add 
mov 
mov 


add 
mov 
mov 


mov 
add 
mov 


[Jr 
xXor 
mov 
mov 
add 


CallMe 


ebp 
ebp, offset CallMe 


ebx, offset CodeStart 

ebx, ebp 

ebx, [ebp+NewEntryPointRVA] 
[ebp+ImageBase] , ebx 


edx, [ebx+3Ch] 

edx, [ebp+ImageBase] 
[ebp+Buffer] ,edx 

edx,6 

bx, [edx] 

word ptr [ebp+SecNum] ,bx 
edx,7Ah 

edx, [edx] 

edx, [ebp+ImageBase] 


edx,16 
ecx,dword ptr [edx] 
ecx, [ebp+ImageBase] 


edx, [ecx] 
[ebp+_LoadLibrary] , edx 
ecx, 4 

edx, lecx] 

[ebp+ GetProcAddress] ,edx 
eax, [ebp+O0rgEntryPointRVA] 


eax, [ebp+ImageBasel] 
[ebp+0rgEP] ,eax 


****Secciones para descodificar+****x**/ 
ecx, ecx 

edi, [ebp+SecNum] 

eax, [ebp+Buffer] 

eax, 0F8h 
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MainDecodeLoop: 
cmp di,cx 
jz DecodingDone 


push edi 

mov ebx, [eax] 

cmp ebx, 77656E2Eh 
jz NoDecoding 

cmp ebx, 7273722Eh 
jz NoDecoding 

cmp ebx,63727372h 
jz NoDecoding 

cmp ebx, 6C65722Eh 
jz NoDecoding 

cmp ebx, 6F6C6572h 
jz NoDecoding 

cmp ebx, 6164652Eh 
jz NoDecoding 

cmp ebx,736C742Eh 
jz NoDecoding 


add eax, 8 
mov edi, [eax] 
add eax,4 
mov ebx, [eax] 
add eax,4 
mov edx, [eax] 
add eax,4 
mov esi, [eax] 


cmp esi,0 
jz SectionDecoded 
cmp edx, 0 
jz SectionDecoded 


cmp edi,edx 
jnl TakeSizeOfRawData 
mov edx,edi 


TakeSize0fRawData: 
mov esi, [ebp+ImageBase] 
add ebx,esi 
call SimpleCrypt 
jmp SectionDecoded 


NoDecoding: 
add eax, 14h 
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SectionDecoded: 
add eax, 14h 
inc cx 
pop edi 
jmp MainDecodeLoop 


DecodingDone: 
mov edx, [ebp+0rglIT] 
add edx, [ebp+ImageBase 
mov eax, [edx] 
add eax, [ebp+ImageBase 
mov [ebp+0rgFirstThunk] ,eax 
add edx, 12 
mov eax, ledx] 
add eax, [ebp+ImageBase 
mov [ebp+Namel] ,eax 
add edx,4 
mov eax, [edx] 
add eax, [ebp+ImageBasel] 
mov [ebp+FirstThunk],eax 
add edx,4 
mov [ebp+Buff£er] ,edx 


/*kkk***Proceso con las funciones importadas ***x*x*x*x*/ 
MainITLoop: 
mov ecx, [ebp+ImageBase] 
cmp [ebp+FirstThunk] ,ecx 
jz MainITEnd 


mov ebx, [ebp+Name1] 
push ebx 
mov eax, [ebp+_LoadLibrary] 
call eax 
mov ebx,eax 


mov ecx, [ebp+ImageBase] 

cmp [ebp+OrgFirstThunk] ,ecx 
jnz Nothing 

mov eax, [ebp+FirstThunk] 
mov [ebp+0rgFirstThunk] ,eax 


| Nothing: 
mov ecx, [ebp+0rgFirstThunk] 
mov eax, [ecx] 
mov [ebp+0rgThunkDatal ,eax 
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SecondITLoop: 
cmp [ebp+0rgThunkData] , 0 
jz OrgThunkJMP 
mov eax, [ebp+0rgThunkData] 
and eax, IMAGE_ORDINAL FLAG32 
cmp eax,0 
jnz Ordinal 


mov ecx, [ebp+0rgThunkData] 
mov edx, [ebp+ImageBase] 

add edx, 2 

add ecx, edx 

mov edi,ecx 

push edi 

push ebx 

mov eax, lebp+ GetProcAddress] 
call eax 

jmp Jump 


Ordinal : 
mov eax, [ebp+0rgThunkData] 
sub eax,80000000h 
push eax 
push ebx 
mov eax, lebp+ _GetProcAddress] 
call eax 


JUMp : 
mov esi, [ebp+FirstThunk] 
mov dword ptr [esi],eax 
mov ecx, [ebp+0rgFirstThunk] 
mov edx, [ebp+FirstThunk] 
add ecx,4 
add edx,4 
mov [ebp+OrgFirstThunk] ,ecx 
mov [ebp+FirstThunk],edx 
mov eax, [ecx] 
mov [ebp+OrgThunkData] ,eax 
jmp SecondITLoop 


OrgThunkJMP : 
mov edx, [ebp+Buffer] 
mov eax, [edx] 
add eax, [ebp+ImageBase] 
mov [ebp+OrgFirstThunk] ,eax 
add edx,12 
mov eax, [edx] 
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add eax, [ebp+ImageBase] 

mov [ebp+Namel] ,eax 

add edx,4 

mov eax, [edx] 

add eax, [ebp+ImageBase] 

mov [ebp+FirstThunk] ,eax 

add edx,4 

mov [ebp+Bu£fer] ,edx 

jmp MainITLoop 
MainITEnd: 

/**exrr*rEjemplo de invocación de función API*******/ 
mov eax, ebp+ LoadLibrary] 
mov ecx, offset User32 
add ecx,ebp 
push ecx 
call eax 
mov ebx, eax 
mov ecx, offset Function 
add ecx, ebp 
mov eax, [ebp+ GetProcAddress] 
push ecx 
push ebx 
call eax 
push 40h 
call eax 
mov eax, [ebp+OrgEP] 
pop ebp 
pop edi 
pop esi 
pop edx 
pop ecx 
pop ebx 

/**e****kVuelta al Program Entry Point original*****x*x*/ 
jmp eax 

/*xkerrsencillo algoritmo de des/codificación+****x*x*/ 

SsimpleCrypt: 
push ecx 
push eax 


xor 


ecx, ecx 
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DecodeLoop: 


cmp 


edx,ecx 


jz DecodeDone 


mov 
xor 
mov 
inc 
iná 
Jmp 


DecodeDone: 


pop 
pop 


ret 


al, [ebx] 
al, 0ABh 
[ebx] ,al 
ebx 

ecx 
DecodeLoop 


eax 
ecx 


[RRA RA Variables ******/ 
VariablesStart: 


/***k***Variables de inicialización*****x*x*x*/ 
NewEntryPointRVA: 
_ emit O 
_ emit 0 
_ emit O 
_ emit 0 


OrgEntryPointRVA: 
_ emit 0 


_emit 
_ emit 
_ emit 


OXRYIT: 


_ emit 
_ emit 
_ emit 
mit 


ooo 


oooo 


/****Variables empleadas cuando se ejecute el programa**x*x*/ 
_LoadLibrary: 


_ emit 
_ emit 
_ emit 
_ emit 


oooo 
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_GetProcAddress: 
_ emit O 
_ emit 
_ emit 
_ emit 


ooo 


ImageBase: 
_ emit 
_ emit 
_ emit 
_ emit 


oooo 


OrgEP: 
_ emit 
_ emit 
_ emit 
_ emit 


oocooo 


SecNum: 
_ emit 
_ emit 


oo 


OrgFirstThunk: 
_ emit 
_ emit 
_ emit 
_ emit 


oooo 


FirstThunk: 
_ emit 
_ emit 
_ emit 
_ emit 


oooo 


Namel : 
_ emit 
_ emit 
_ emit 
_ emit 


oooo 


OrgThunkData: 
_ emit 
_ emit 
_ emit 
_ emit 


oooo 
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Buffer: 
—emit. 
_ emit 
_ emit 
_ emit 


oooo 


/***Variables necesarias para invocar una función API**x*/ 


Function: 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 
— mit 
_ emit 


User32: 
_ emit 
_ emit 
_ emit 
_ emit 
_ emit 


CodeEnd:; 


) 


0Ox4D 
0x65 
0x73 
0x73 
0x61 
0x67 
0x65 
0x42 
0x65 
0x65 
0x70 


DWORD CPEcoderDlg: : PEA1lign (DWORD Num, DWORD AlignTo) 


( 


/***Función para el cálculo de alineamiento xx */ 
while(Num % AlignTo != 0) 


( 
) 


return Num; 


) 


Num++; 


240 CRACKING SIN SECRETOS CRA-MA 


void CPEcoderDlg: :WritePEFile (LPVOID pMem, HANDLE 
File,DWORD Size) 

( 
/**Función para escribir los contenidos de la memoria 
en el fichero **/ 
DWORD BytesWritten; 


SetFilePointer (File, 0,NULL, FILE_BEGIN) ; 
WriteFile (File, pMem, Size, £BytesWritten, NULL); 
SetFilePointer (File, Size, NULL, FILE_BEGIN) ; 
SetEndofFile (File); 


) 


void CPEcoderDlg::ProcessTLS (BYTE *pMem, DWORD 
VAddress,PIMAGE_NT_HEADERS pImageNT , DWORD 
FileSize,DWORD Offset) 


/*xxxkkpunción para procesar TLSAAARARA Y 

memcpy ( (VOID*) (pMem+FileSize+CODE_SIZE+0x61), (pMem+0££s 
et) sizeof IMAGE TLS_DIRECTORY32); 

pImagenNT- 
>0ptionalHeader.DataDirectory [9] .Virtualáddress = 
VAddress+CODE_SIZE+0x61; 


) 


void CPEcoderDlg::ProcessPE (char* source, char* target) 


PIMAGE NT HEADERS pImageNT'; 
DWORD NOBR; 


/***xxobtención de manejador del fichero fuente ***x*x*/ 
HANDLE File = 
CreateFile (source, GENERIC_READ, FILE_SHARE_READ, NULL, OP 
EN EXISTING, FILE ATTRIBUTE_NORMAL, NULL); 


if (File == INVALID_HANDLE VALUE) 

( 

MessageBox ("¡El fichero no se puede abrir en modo 
lectura! ",NULL,MB_OK | MB_ICONINFORMATION) ; 

return; 


) 


/**xkkxkCarga de variables globalest***x*x*x*/ 
AddedCode () ; 


/*****Carga del fichero en memoria y 
reinicialización*****/ 
DWORD FileSize = GetFileSize (File, NULL); 
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if (FileSize == 0) 
MessageBox ("¡No están permitidos ficheros de tamaño 
nulo!",NULL,MB_OK | MB_ICONINFORMATION) ; 
CloseHandle (File); 


return; 

) 
DWORD Size = FileSize+CODE_SIZE+OTHER_SIZE+0x1000; 
BYTE *pMem = new BYTE [Size]; 


for (DWORD i = 0; i < Size; 1++) 
( 
pMem[i] = 0; 


) 


ReadFile (File, pMem, FileSize, £NOBR, NULL) ; 
pImageNT = ImageNtHeader ( (VOID*) pMem) ; 


/[**kk*Verificación del formato PE*****x*x*/ 
if (pImageNT == 0) 


MessageBox ("¡Fichero con formato PE 
incorrecto! ",NULL,MB_OK | MB_ICONINFORMATION) ; 
CloseHandle (File); 
delete pMem; 
return; 


) 


/****kVerificación de la existencia de la tabla de 
importaciones ***x*/ 
DWORD ITRVA = pImagenT- 
>0ptionalHeader.DataDirectory [1] .VirtualAddress; 
if (ITRVA == 0) 
( 
MessageBox ("¡Ninguna función importada?",NULL,MB_OK | 
MB_TCONINFORMATION) ; 
CloseHandle (File); 
delete pMem; 
return; 


) 


/**x*****Nueva sección, inicialización y redirección de 
valores necesarios ****x*/ 

DWORD NewSize = AddSection (pMem, pImageNT) ; 

if (NewSize == 0) 


( 


CloseHandle (File); 


242 CRACKING SIN SECRETOS O RA-MA 


delete pMem; 
return; 


) 


/*******Codificación de secciones en el fichero*****x**/ 
CryptPE (pImageNT, pMem) ; 


/***x0btención del manejador del fichero de 
destino+*x**x*/ 

HANDLE NewFile = CreateFile (target,GENERIC WRITE | 
GENERIC_READ, FILE_SHARE WRITE | 
FILE SHARE READ, NULL, CREATE_ALWAYS,FILE_ATTRIBUTE_NORM 
AL,NULL); 

if (NewFile == INVALID HANDLE VALUE) 

( 
MessageBox ("¡No se puede crear el fichero!" ,NULL,MB_OK 

| MB_ICONINFORMATION) ; 

CloseHandle (File); 
delete pMem; 
return; 


) 


[*******Guardando el fichero****x*x*x*/ 
WritePEFile (pMem, NewFile,NewSize) ; 
MessageBox ( "¡Hecho! ", NULL, MB_OK | MB_ICONINFORMATION) ; 


CloseHandle (File); 
CloseHandle (NewFile) ; 
delete pMem; 


) 


IMAGE _SECTION_HEADER 
CPEcoderDlg::RvaToSection(PIMAGE_NT_HEADERS 
pImageNT,BYTE *pMem, DWORD Adr0fSecTable,BOOL 
AdjustChar) 


( 


/*****Función para obtener parámetros de la 
sección*****x*x*/ 

PIMAGE SECTION HEADER pSection; 

IMAGE SECTION HEADER Section; 

DWORD vaddr'; 


memcpy (vaddr, (VOID*) (Adr0fSecTable+12), sizeof DWORD); 
pSection = ImageRvaToSection (pImageNT,pMem, vaddr) ; 
if (pSection == 0) 
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/*******Guardando parámetros de sección en variables 
HR 

DWORD vsize,raddr,rsize, characteristics; 

memcpy ($vsize, (VOID*) (Adr0fSecTable+8),sizeof DWORD); 

memcpy (£rsize, (VOID*) (Adr0fSecTable+16),sizeof DWORD) ; 

memcpy (Sraddr, (VOID*) (AdrofSecTable+20),sizeof DWORD) ; 

memcpy (characteristics, (VOID*) (AdrofsecTable+36), 
sizeof DWORD); 


Section.VirtualAddress = vaddr; 
Section.Misc.VirtualSize = vsize; 
Section.PointerToRawData = raddr; 
Section.SizeOfRawData = Ysize; 


if (AdjustChar) 
Section.Characteristics = characteristics | 
0x80000000; 


return Section; 


if (AdjustChar) 
pSection->Characteristics = pSection->Characteristics 
0x80000000; 


Section = *pSection; 
return Section; 


) 


void CPEcoderDlg::SimpleCrypt (BYTE *pInput,DWORD 1Size) 


/*ex**Algoritmo sencillo de codificación******x*/ 
for (DWORD lCount = 0; lCount < lSize ; 
1Count++,pInput++) 


( 


*pInput *= OxAB; 


) 


void CPEcoderDlg::AssembleIT(BYTE *pMem, DWORD 
NewSectionRAW, DWORD NewSectionVA, PIMAGE_NT_HEADERS 
pImageNT) 


/***Función para crear una tabla de importaciones 
nueva***/ 

DWORD *Name = new DWORD; 

DWORD *FirstThunk = new DWORD; 

DWORD *ThunkLoadLibrary = new DWORD; 

DWORD *ThunkGetProcAddress = new DWORD; 
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NewSectionRAW += CODE SIZE; 
NewSectionVA += CODE_SIZE; 


/**Creación de estructuras de la tabla de 
importaciones**/ 
*Name = NewSectionVA+2*sizeof 
IMAGE IMPORT _DESCRIPTOR+3*sizeof 
IMAGE _THUNK_DATA+12+1+14+14+2*sizeof WORD; 
*FirstThunk = NewSectionVA+2*sizeof 
IMAGE IMPORT _DESCRIPTOR; 


memcpy ( (VOID*) (pMem+NewSectionRAW+12) ,Name, sizeof 
DWORD) ; 

memcpy ( (VOID*) (pMem+NewSectionRAW+16),FirstThunk, 
sizeof DWORD); 


*ThunkLoadLibrary = NewSectionVA+2*sizeof 
IMAGE_IMPORT_DESCRIPTOR+3*sizeof IMAGE THUNK_DATA; 
*ThunkGetProcAddress = NewSectionVA+2*sizeof 
IMAGE _IMPORT_DESCRIPTOR+3*sizeof 
IMAGE _THUNK_DATA+sizeof WORD+12+1; 


memcpy ( (VOID*) (pMem+NewSect ionRAW+2*sizeof 
IMAGE_IMPORT_DESCRIPTOR) , (VOID*) ThunkLoadLibrary,sizeo 
£ IMAGE _THUNK_DATA); 

memcpy ( (VOID*) (pMem+NewSect ionRAW+2*sizeof 
IMAGE_IMPORT_DESCRIPTOR+sizeof 
IMAGE THUNK_DATA) , (VOID*) ThunkGetProcAddress, sizeof 
IMAGE THUNK_DATA) ; 


[+A **LOadLibraryAr**k*xx/ 

DWORD Adresa = NewSectionRAW+2*sizeof 
IMAGE IMPORT _DESCRIPTOR+3*sizeof 
IMAGE THUNK_DATA+sizeof WORD; 


pMem[Adresa] = 0x4C; 

pMem [Adresa+1] = 0x6F; 
pMem[Adresa+2] = 0x61; 
pMem[Adresa+3] = 0x64; 
pMem [Adresa+4] = 0x4C; 
pMem [Adresa+5] = 0x69; 
pMem [Adresa+6] = 0x62; 
pMem [Adresa+7] = 0x72; 
pMem[Adresa+8] = 0x61; 
pMem[Adresa+9] = 0x72; 
pMem[Adresa+10] = 0x79; 
pMem[Adresa+11] = 0x41; 


(CO RA-MA 


CAPÍTULO 7: EL FORMATO PE Y SUS HERRAMIENTAS 245 


) 


/*******GetProcAddress******x*/ 
Adresa = NewSectionRAW+2*sizeof 
IMAGE IMPORT DESCRIPTOR+3*sizeof 


IMAGE THUNK_. 


pMem 
pMem 
pMem 
pMem 
pMem 
pMem 
pMem 
pMem 
PpMem 
pMem 
pMem 
pMem 
pMem 
pMem 


Adresal] = 
Adresa+1 
Adresa+2 
Adresa+3 
Adresa+4 
Adresa+5 
Adresa+6 
[Adresa+7 
[Adresa+8 
[Adresa+9 
Adresa+10 
Adresa+11 
[Adresa+12 
Adresa+13 


] 
] 
] 
] 


DATA+2*sizeof WORD+12+1; 


0x47; 
= ¡0Xx65$ 


0x74; 
Ox50; 
DXTMZ; 
0x6F'; 
0x63; 


= 0x41; 
= 0x64; 


" 


" 


ul 


0x64; 
0x72; 
0x65; 
0x73; 
0x73; 


Jer k*kernel32,011*******/ 
Adresa = NewSectionRAW+2*sizeof 
IMAGE _IMPORT_DESCRIPTOR+3*sizeof 
IMAGE THUNK_DATA+2*sizeof WORD+12+1+14+1; 


pMem[Adresa] = 0x6B; 
pMem[Adresa+1] = 0x65; 
pMem [Adresa+2] = 0x72; 
pMem [Adresa+3] = 0x6E; 
pMem [Adresa+4] = 0x65; 
pMem [Adresa+5] = 0x6C; 
pMem[Adresa+6] = 0x33; 
pMem [Adresa+7] = 0x32; 
pMem [Adresa+8] = 0x2E; 
pMem[Adresa+9] = 0x64; 
pMem[Adresa+10] = 0x6C; 
pMem [Adresa+11] = 0x6C; 
delete ThunkGetProcAddress; 
delete ThunkLoadLibrary; 
delete FirstThunk; 


delete Name; 


void CPEcoderDlg::CryptPE(PIMAGE_NT_HEADERS 
pImageNT,BYTE *pMem) 


( 
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/****Función para codificar secciones en el 
fichero**x*x*/ 
IMAGE _SECTION_HEADER *pSection = new 
IMAGE _SECTION_HEADER; 
DWORD SecNum = pImageNT->FileHeader.Number0fSections; 
DWORD AdrOfSecTable; 


for (DWORD i = 0; i < SecNum; 1++) 


Adr0fSecTable = (DWORD) pImageNT+ (sizeof 
IMAGE_NT_HEADERS) +1* (sizeof IMAGE SECTION_HEADER); 


*pSection = 
RvaToSection (pImageNT,pMem, Adr0fSecTable, FALSE) ; 

if (* (LPDWORD) pSection->Name != 0x77656E2E /*".new"*/ 
$b 


0x7273722E /*".rsr"*/ £% 
0x63727372 /*"rsrc"*/ £8 
0x6C65722E /*".rel"*/ £8 
= 0x6F6C6572 /*"relo"*/ 8 
= 0x6164652E /*".eda"*/ 8 
= 0x736C742E /*.tls*/ ££ 


* (LPDWORD) pSection->Name ! 
* (LPDWORD) pSection->Name ! 
* (LPDWORD) pSection->Name ! 
1 
1 
! 


Ú 


* (LPDWORD) pSection->Name 
* (LPDWORD) pSection->Name 
* (LPDWORD) pSection->Name 


pSection->PointerToRawData != 0 £86 pSection- 
>SizeOfRawData != 0) 
DWORD Size = (pSection->Misc.VirtualSize < pSection- 


>SizeOfRawData ? pSection->Misc.VirtualSize 
pSection->SizeOfRawData) ; 
SimpleCrypt (pMem+pSection->PointerToRawData, Size); 


) 


delete pSection; 


) 


DWORD CPEcoderDlg: :AddSection (BYTE 
*pMem, PIMAGE_NT_HEADERS pImagenNT) 
( 
/*******Función para añadir, inicializar una sección 
nueva y redirigir valores concretos****x*x*x*/ 
IMAGE _SECTION_HEADER *pSection = new 
IMAGE SECTION_HEADER; 
DWORD SecNum = pImageNT->FileHeader.NumberOfSections; 
DWORD SecSize = sizeof IMAGE SECTION HEADER; 
DWORD Size = (SecNum+1)*SecSize; 
DWORD TotalSize = (DWORD)pImageNT- 
(DWORD) pMem+Size+sizeof IMAGE _NT HEADERS; 
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DWORD HeadersSize = plImagenT- 
>OptionalHeader.SizeOfHeaders; 


/****Comprobación de espacio en la tabla de 
secciones***x*/ 
if (TotalSize > HeadersSize) 
( 
MessageBox ("¡Espacio insuficiente en la tabla de 
secciones !",NULL,MB_OK | MB_ICONINFORMATION) ; 
return 0; 


/****Obtención de los parámetros de la última 
sección**x*x*/ 
DWORD AdrOfSecTable; 
for (DWORD i = 0; ¡1 < SecNum; 1++) 
( 
Adr0fSecTable = (DWORD) pImageNT+sizeof 
IMAGE_NT_HEADERS+1* (sizeof IMAGE SECTION_HEADER) |; 
*pSection = 
RvaToSection (pImageNT, pMem, Adr0fSecTable, TRUE) ; 
) 


unsigned char Namel [8] = ".new"; 
DWORD *VirtualAddress = new DWORD; 
DWORD *VirtualSize = new DWORD; 
DWORD *SizeOfRawData = new DWORD; 
DWORD *PointerToRawData = new DWORD; 
DWORD *Characteristics = new DWORD; 


/*****Cálculo de los parámetros de la sección 
nuevar**x*x*/ 

*VirtualAddress = PEAlign (pSection- 
>VirtualAddress+pSection->Misc.VirtualSize,pImageNT-> 
OptionalHeader.SectionAlignment) ; 

*VirtualSize = CODE_SIZE+OTHER_SIZE; 

*SizeOfRawData = PEAlign(CODE_SIZE+OTHER_SIZE,pImageNT- 
>O0ptionalHeader.FileAlignment); 

*Characteristics = OxE00000E0; 

*PointerToRawData = pSection- 
>PointerToRawData+pSection->SizeOfRawData; 


/*****k**Inicializando el campo de las variables*****x*x*/ 


VAR[0] = *VirtualAddress; 
VAR [1] = pImageNT->OptionalHeader.AddressOfEntryPoint; 
VAR[2] = pImageNT- 


>OptionalHeader.DataDirectory [1] .VirtualAddress; 
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DWORD RealSize = *SizeOfRawData+*PointerToRawData; 
DWORD Adresa = AdrO0fSecTable+sizeof 
IMAGE SECTION HEADER; 


/*r*xrr*Grabando la definición de la sección nueva en 
la tabla de secciones*t****x*x*/ 

memcpy ( (VOID*) (Adresa) ,Namel, sizeof Namel) |; 

memcpy ( (VOID*) (Adresa+8) , (VOID*) VirtualSize,sizeof 


(VOID*) (Adresa+12), (VOID*) VirtualAddress, sizeof 


; 
(VOID*) (Adresa+16) , (VOID*) SizeOfRawData, sizeof 

memcpy ( (VOID*) (Adresa+20) , (VOID*) PointerToRawData, sizeo 
f DWORD) ; 

memcpy ( (VOID*) (Adresa+36) , (VOID*) Characteristics, sizeof 
DWORD) ; 


/*kkkkkkInsertando el código de control******x*/ 
memcpy ( (VOID*) (pMem+*PointerToRawData) , (VOID*) 
(CODE_START) CODE_SIZE) ; 


/*******Insertando variables***x*x*x*/ 
memcpy ( (VOID*) (pMem+*PointerToRawData+VAR_START) , (VOID* 
) VAR, sizeof VAR); 


Jkxxe***Corrigiendo valorest***k****kxx/ 

pImageNT->FileHeader.Number0fSections += 1; 

pImageNT->OptionalHeader.SizeOfImage += *SizeO0fRawData; 

pImageNT->OptionalHeader.SizeO0fCode += *SizeOfRawData; 

pImageNT->OptionalHeader.SizeOfInitializedData += 
*SizeO0fRawData; 


/**k****Procesando la tabla de importaciones *****x*x*/ 

AssemblelIT (pMem, *PointerToRawData, *VirtualAddress, 
pImagenT) ; 

pImagenNT- 
>OptionalHeader.DataDirectory [1] .VirtualAddress = 
*VirtualAddress+CODE_SIZE; 


SA 
1f (pImageNnT- 
>OptionalHeader.DataDirectory [9] .VirtualAddress != 0) 
( 
PIMAGE SECTION _HEADER Section = 
ImageRvaToSection (pImageNT, pMem, pImageNT- > 
OptionalHeader.DataDirectory [9] .VirtualAddress) ; 
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DWORD Offset = pImageNT- 
>OptionalHeader.DataDirectory[9] .VirtualAddress- 
Section->VirtualAddress+Section-> PointerToRawData; 


ProcessTLS (pMem, *VirtualAddress,pImageNT, *PointerToRaw 
Data, Offset); 


) 


/*kke**Redirigiendo Program Entry Point******x*/ 
pImageNT->OptionalHeader.AddressOfEntryPoint = 
*VirtualAddress; 


delete Characteristics; 
delete PointerToRawData; 
delete SizeOfRawData; 
delete VirtualSize; 
delete VirtualAddress; 
delete pSection; 


return RealSize; 


) 


void CPEcoderDlg|: :OnOk () 

( 
/***k***Selección del fichero fuente y destino ****x*x**/ 
OPENFILENAME Open; 
char Source [5137 = ""; 


Open.]StructSize = 76; 

Open.hwndOwner = NULL; 

Open.hInstance = NULL; 

Open.lpstrFilter = "EXE files (*.EXE)10*.EXEXMOXO"; 

Open.lpstrCustomFilter = NULL; 

Open.nMaxCustFilter = NULL; 

Open.nFilterindex = NULL; 

Open.lpstrFile = Source; 

Open.nMaxFile = 512; 

Open.lpstrFileTitle = NULL; 

Open.nMaxFileTitle = NULL; 

Open.lpstrInitialDir = NULL; 

Open.lpstrTitle = "Por favor, indique el fichero que 
desea codificar"; 

Open.Flags = OFN_FILEMUSTEXIST | OFN_HIDEREADONLY | 
OFN EXPLORER | OFN_PATHMUSTEXIST; 

Open.nFileOffset = NULL; 

Open.nFileExtension = NULL; 

Open.lpstrDefExt = NULL; 
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Open.lCustData = NULL; 
Open.lpfnHook = NULL; 
Open. lpTemplateName = NULL; 


BOOL Selected = GetOpenFileName (£Open) ; 


if (Selected) 

( 

OPENFILENAME Open2; 
char Target [512] = ""; 


Open2.1StructSize = 76; 
Open2.hwndOwner = NULL; 
Open2.hInstance = NULL; 
Open2.1pstrFilter = "A11 files (*.*)l0*.*10l0"; 
Open2.1pstrCustomFilter = NULL; 
Open2.nMaxCustFilter = NULL; 
Open2.nFilterIndex = NULL; 
Open2.1pstrFile = Target; 
Open2.nMaxFile = 512; 
Open2.1pstrFileTitle = NULL; 
Open2.nMaxFileTitle = NULL; 
Open2.1pstrInitialDir = NULL; 
Open2.1pstrTitle = "Guardar a..."; 
Open2.Flags = OFN_OVERWRITEPROMPT | OFN_HIDEREADONLY | 
OFN_EXPLORER; 
Open2.nFileOffset = NULL; 
Open2.nFileExtension = NULL; 
Open2.lpstrDefExt = NULL; 
Open2.1CustData = NULL; 
Open2.1pfnHook = NULL; 
Open2.lpTemplateName = NULL; 


BOOL Selected2 = GetOpenFileName (£Open2) ; 


if (Selected2) 


( 
ProcessPE (Source, Target) ; 
) 
) 
) 
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PROTECCIONES ALTERNATIVAS 


Cargador de símbolos AntiSoftICE 


Aunque éste sea un viejo y bien conocido truco, figura aquí para completar la lista 
de posibilidades en este campo. Pretende evitar que SoftICE interrumpa el programa en la 
dirección del Program Entry Point una vez que lo arranque el cargador de símbolos. 


Resulta muy sencillo de utilizar. El cargador de símbolos interrumpirá el 
programa en la dirección del Program Entry Point sólo si esta dirección fuera 
sustituida en una sección cuyas características contuviese el indicador contains 
excecutable code. Por lo tanto, si se alterasen las características de esta sección 
(sección con código ejecutable, cuyo nombre normalmente es .next, CODE, etc.) con 
algún editor PE (o directamente) para comprobar que no contiene el indicador 
anteriormente mencionado, el problema quedaría resuelto. Posiblemente la forma más 
cómoda de llevar esto a cabo sea mediante un editor PE denominado PEditor, incluido 
en el CD adjunto. 


¡Section Characteristic Wizard 


¡Flags of the Characteristics of the Section: 


IT” sharable in memory z 
IV executable as code do nothing 
[Y teadable 
7 witeable 1 
7 contains extended relocations 
TT discardable as needed 

JT” can be cached 

T not pageablo 


IT” contains COMDAT data 


T” contains comments or othes infos 
TT wilinot become part of the image 


| take it 
: 
| 


TT” contains urinitialized data 1 o] 
T” shout bo padded o next boundayy | 50000020 | 


[Click on the checkboxes to build your own characteristics]... 


Figura 7-11. Comodidad para definir las características de las secciones con 
PEditor 


Dada su fama, no deben ponerse grandes esperanzas en este método. Ahora bien, si 
se incluye la comprobación de las características de una sección, puede ofrecer buenos 
resultados. 
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Comprobación del punto de entrada al programa 


Ya se ha mencionado con anterioridad la gran importancia que tiene el valor del 
Program Entry Point original. Lo que faltaba por indicar es que el valor del 
Program Entry Point actual puede emplearse, sencillamente, para saber si el 
fichero se ha descodificado. 


Su lógica es muy sencilla. Cuando el programa se descodifique, el Program 
Entry Point volverá a su valor original antes descodificarse. Bastará con situar la 
comprobación del valor actual y del nuevo Program Entry Point creado por el 
codificador PE en algún punto del programa. Si estos dos valores no fueran iguales, 
sería obvio que el programa sí se ha descodificado y que el Program Entry 
Point ha cambiado a su valor original. En este caso, la mejor solución pasaría por 
provocar un error en el programa para hacer creer al posible cracker que ha cometido 
un error en la descodificación. 


Nunca deberá compararse el valor correcto de Program Entry Point con 
el actual, De esa manera se podría hallar el valor original directamente a partir del 
programa. Debe compararse el valor actual de Program Entry Point con el 
nuevo valor creado por el codificador PE. 


Ahora bien, esta comprobación se puede sortear con facilidad situando una 
instrucción de bifurcación al Program Entry Point original en la dirección del 
Program Entry Point creada por el codificador PE. No obstante, al ser tan 
infrecuente este tipo de comprobación en los programas, resultará muy improbable que la 
contemple el posible cracker. 


RSA 


Este algoritmo de codificación asimétrica, creado entre los años 1977 y 1978 por 
Ron Rivest, Adi Shamir y Leonard Adleman, constituye uno de los estándares no oficiales 
de hoy en día. La seguridad de este algoritmo radica en la gran dificultad para obtener 
grandes números a partir de la multiplicación de otros números primos grandes, la solución 
dependerá, por lo tanto, del cálculo de los factores del producto. Su seguridad es 
proporcional a la longitud de la clave. Cualquier grupo o empresa especializada podrá 
anular fácilmente claves con una longitud de 384 bits. Aunque resulte difícil comprobarlo, 
se considera que una clave con una longitud de 1024 bits es lo suficientemente buena 
como para defenderse incluso de las entidades gubernamentales. 


Actualmente existen muchos algoritmos rápidos y seguros, como los criptosistemas 
elípticos (ECC), que obtienen un nivel de seguridad comparable a RSA con una clave de 
longitud de 2048 bits aunque utiliza una clave de 160 a 180 bits de longitud. Todo ello 
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indica que la criptografía está constantemente evolucionando y que los antiguos 
algoritmos, como el RSA, van perdiendo su utilidad. 


No se detallará aquí el concepto matemático específico de RSA ni el 
funcionamiento real de este algoritmo. Sí se indicará, sin embargo, el procedimiento para 
crear una pareja de claves correcta en un par de pasos con ejemplos de algoritmos útiles 
(aptos incluso para aquellos que no sean muy aficionados a las matemáticas) con ejemplos 
prácticos para codificar y descodificar datos mediante RSA. 


1. En primer lugar, definanse dos números primos diferentes, P y Q. Estos números 
se emplearán posteriormente para calcular los valores de las claves. El múltiplo de P y Q, 
con frecuencia denominado N, será la parte pública y también la parte privada de la clave. 
Ello explica la importancia de seleccionar números primos tan grandes como sea posible 
para procurar que sea muy difícil hallar los números primos P y Q a partir de N y poder así 
anular el código. Con objeto de evitar un procedimiento excesivamente largo, no se 
emplearán números primos de, por ejemplo, 1024 bits, sino números y claves menores. 


A continuación se muestra una función que obtiene el número primo mayor más 
próximo a otro dado: 


__int64 CRSADIg: :GetPrime(__int64 start) 


( 


_ int64 i,Num,Sgrt; 


if (start <= 0 || start == 1 || start == 2) 
return 2; 
else 
( 
Num = start; 
if (Num % 2 == 0) // ¿número par? 
Num++; // en caso afirmativo, sustituir 
// por impar 


= (__int64)sqrt (Num); // raíz 
for (1 = 3; 1 <= Sagrt; 1 += 2) If. ii si4+2 = 
// sólo números 
// impares 


if (Num % i == 0) //  ¿múmero divisible 


// sin resto? 


Num += 2; 
Sqrt = (__int64)sqrt (Num); 
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else if (i == Sqrt) // ¿hallado número 
// primo? 
break; 


) 


return Num; 


) 
) 


2. En segundo lugar, determínese el valor de la parte pública de la clave (para 
codificar) bajo E; este valor deberá ser menor al múltiplo de (P-1)(Q-1) y el mayor común 
divisor a estos dos números deberá ser 1. Lógicamente significa que debe ser un número 


impar. 


La función siguiente obtendrá el mayor divisor común de dos números dados: 


__int64 CRSAD1g: :GetLCD(__int64 a, _int64 b) 


( 


/***Posibilidad alternativa de procesar números 


negativos***/ 
// a= abs (a); 
// b = abs (b); 


/*kkx* las siguientes dos opciones serán imposibles si 
los números a y b son primos****x*x*x*/ 
if (a == || hb <= 0) 


e lt=1]|»=i 


while (a != b) // cálculo del mayor divisor común 


return a; 


) 


Ya resulta factible crear un bucle que calcule el número E correcto superior y más 
próximo a otro dado (en el ejemplo, indicado por determined number), siendo 1 el 
mayor común divisor de los números E y (P-1)(Q-1). 
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dwhile (determined _ number < (p-1)*(q-1)) 


( 
if (GetLCD (determined number, (p-1)*(q-1)) == 1) 
( 
// hallado número E 
// E = determined_number; 
break; 
) 
determined _number++; 
) 


3. Calcúlese el valor de la parte privada de la clave D (para descodificar); DE-l 
deberá ser divisible sin resto por (P-1)(Q-1). La expresión matemática de esta operación 
será la siguiente: 


DE = 1 (mod (P-1) (Q-1)) 


Debe encontrarse un número X entero para quien D sea uno número entero y 
cumpla la expresión siguiente: 


D=(X(P-1(Q-1) + 1) /E 


La función siguiente obtendrá el número D y utilizará los valores iniciales y finales 
para calcular el número X, utilizando P, Q y E como parámetros: 


__ int64 CRSADlg: :GetD(__int64 start,  int64 end, _int64 
p,  int64 q,_int64 e) 


( 


_ int64 x,k = (p-1)*(q-1); 


[*k*****En caso de valores negativos para las variables 
iniciales y finales *****x**/ 

// start = abs (start); 

// end = abs (end); 


if (start >= end) 


( 

MessageBox(" El valor inicial para determinar el 
múltiplo del número X deberá ser inferior al 
valor final” ,NULL,MB_OK | MB_ICONINFORMATION) ; 

return 0; 

) 
if (start == 0) 
start = 1; 
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for (x = start; x <= end; X++) 


( 
if ((x*k+1) $ e == 0) // ¿hallado número D? 
_ int64 d = (x*k+1) / e; 
return d; 
) 
) 
return 0; 


4. Supóngase que T representa los datos que se han de codificar. Estos datos se 
codificarán de la manera siguiente: (T*E) mod PQ. 


5. Supóngase que C representa los datos codificados que se han de descodificar. 
Estos datos se descodificarán de la manera siguiente: (C*D) mod PQ. 


Bastará con emplear una sencilla calculadora basada en los algoritmos 
anteriormente mencionados para hallar la pareja de claves necesaria en RSA, Si aún no se 
supiera cómo o se prefiriera no hacerlo, este programa se podrá encontrar además de su 
código fuente en el CD adjunto. 


Ejemplo de aplicación con RSA 
P=61 
Q=53 
PQ = 3233 
E=17 
D=2753 
Parte pública de la clave: (PQ,E) = (3233,17) 
Parte privada de la clave: (PQ,D) = (3233,2753) 
El número 123 se codificará de la siguiente manera: 
encrypt (123)=(123 *17)mod 3233 


=337587917446653715596592958817679803 mod 3233 
=855 
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La descodificación será: 


decrypt (855)=(855 *2753)mod 3233 = 

504328889584160687344228991273944666314538783600355093 
15554967564501055628612082559978744245428110054383498 
65428933638493024645144150785172091796654782635307099 
63803538732650089668607477182974582295034295040790358 
18459409563779385865989368838083602840132509768620766 
97739667533250542826093475735137988063256482639334453 
09259438556242923301751977190016924916912809150596019 
17876017134972543927921569670178990213430714646897127 
96102771813783945869677289869342365240311693217089269 
6176437265213156658331587...(el número entero 
necesitaría un par de páginas)mod 3233 =123 


CONCLUSIÓN SOBRE EL FORMATO PE Y 
COMPRESORES-CODIFICADORES PE 


Así se llega al final del capítulo más largo de este libro. Supone para el lector 
una información básica sobre el formato PE que le permitirá ahondar e investigar este 
tema en mayor profundidad. Si así lo hiciese, descubrirá un gran número de aspectos 
interesantes y otras posibilidades del formato PE que no se han mencionado aquí. 


Ahora el lector ya podrá crear su propio codificador PE y añadirle varias 
protecciones descritas en otros capítulos. 


Los compresores y codificadores PE figuran entre los métodos más utilizados de 
protección y constituyen la base de la inmensa mayoría de las protecciones 
comerciales. Mucha gente comete el error de considerar su programación muy 
compleja y prefieren emplear productos específicos aunque sean conscientes de sus 
limitaciones. 


Gracias a este libro, el primero en su género, ya no resulta necesario, puesto que 
aporta una guía completa para poder programar un codificador PE con sus 
correspondientes aclaraciones y deshacer el misterio y la información errónea que 
injustamente se han asociado a este tema. 


No debe creerse ciegamente a nadie que afirme que Su protección basada en un 
codificador PE sea algo increíblemente complicado y muy difícil de crear por lo que 
merezca la pena pagar desproporcionadas cantidades de dinero. Habiendo considerado 
detenidamente todas las posibilidades anteriormente mencionadas de protección, el 
lector podrá crear su propio codificador PE de mejor calidad que la mayoría de los que 
ya se encuentran en el mercado. Por fin, las empresas “profesionales” especializadas 
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en el software de protección tendrán algún tipo de competencia y se verán en la 
necesidad de considerar seriamente producir y vender productos genuinos de alta 
calidad en vez de sistemas de seguridad elementales vendidos como productos de los 
mejores desarrolladores especialistas en sistemas antipirateo, como ha sido el caso 
hasta ahora, debido a la falta de conocimiento público. Sería deseable que esta 
situación cambiara y que ya nadie más pudiese ganar cifras astronómicas de dinero 
gracias a la ignorancia de la gente. 


La verdad es que los desarrolladores siempre se encuentran un paso por detrás de 
los crackers, nunca llegan a alcanzarlos; por eso siempre es mejor desarrollarlo todo uno 
mismo. A diferencia de los desarrolladores, el lector aprenderá entonces de sus errores (o 
ésa es la esperanza del autor) y no los volverá a repetir. 
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CAPÍTULO 8 


OTROS PROGRAMAS UTILIZADOS POR 
LOS CRACKERS 


——  ——————_—_—_—_— 


REGISTRY MONITOR 


IA El 


NT 


[7 rrocess — Tre 

463 Explorer.exo  QueryValie HKCUISoftweeYMicrosoft Windows! CurrentVersionlExplorerFleExts| EXEUIAOTO: NOTFOUNO- 

464 Expkeerexe Queryey — MECRLENE SUCCESS — Urinowninto Class: 
1465. Exploreraxe Operkey  HCLLexe NOTFOUNO- 

1466 Explorer.exe — QueryValos  HKCRI.EXENDOf uk) SUCCESS — "exelle” 

67 Exdleerere Queres HXCU SUCESS  UinoWn fo Class 
465 Erplorerexe Openkey — HiCUExefie INOTFOUND. 

69 Explreriexe Cperkey — MiCnlexalle SUCCESS — Meyi OXEZSOISEO 
470 Explorer. Querykey — MCRIexefe SUCCESS Unknowm Info Class 
AM Evplrerexe Operkey — HCUOreflalCurver NOTrOUNO, 

472 Esplaceriexe Openkey — INCA leeflaicuVer NOTEOUNO 

473 Expleerone Coseley — PCRiexelde SUCCESS — Key OXEZEBOCEO 
1474. Explorecexe HrcAlexette, SUCCESS Lrkmown info Class, 
476 Explrer.exe QueryYalae HC eseflaBaseciss HOTECUNO: 

77 Explorerine Query MCU SES Urinoanieto Class 
70 Explxerexe Opertey HOTrOLO, 

477 Esclxecina CperKey SUCCESS — May: OsEZEEOCEO 
400. Explorer exe Querer SUCCESS Ll Into Class 
401 Explrerexe Opankey nOTEOLAO 

402 Explorer xo. Cpertey HOTFOLNO 


463 Esplrerese  Querytoy 
404. Exploeeriexe  Operbey 
465 Esplorerere  Queryvals: MECA infoTio 


486 Explorerieto Closekey — MECRIOseÍÓ SUCCESS 
487 Exploreriexe ChoseKey — HECUISoftwarelMMerosoft|WndowslCusrertVersoniEsplorer|FleEnts SUCCESS 

468 Explorerexe Closeley — HECUIScftwaralMarosoltiWedows|CurertversonlExplored Flex DE SUCCESS 

(489 Enplorenexo Chseley — MORLEME SUCCESS 

1490. Explorer.exe Chsekey — FXCRI SUECESS 

481 REGMONEXE Cpenkey — MCUADDEventsISchemeslApos|.DefauKiCOSelect) current, SUCCESS 

482 REGMON.EXE QuerfValie HECUIAREvertelSchemeslAps|_DefautiCCSelectl curenti(Defauk) SUCCESS. 

403 REGMON.XE Ciosekey — HECUIADOEVentsischemeslApos!.DefatiCCSelect] current SUCCESS Ney: DsEZABIESO, 

404 REGMON.ESE Operkey — HKCLIAPOEVertsiSchemes1Apos| DefasRiCCSclect| cuen. ACCESS Key: OXEZ6BOCSO 

(455. REGMON.EJE Query/Value: HECUNADpEvertsischemes|Apes| Defeuk|CCSelect] curentl(Defaut) SuecESs 

dos REGMONEXE Closekey — MKCUNADpEvertelSchemestacos! DefauICCScled! carert SUCCESS — Key: DIEZEBOCEO 

(487. REGMON.EXE Operkey — HECUNAGEVeCEsiSchemestapes] Defanit|CCSelecti current SUCCESS: Key: OXEZEBOCSO 

(458 REGMONEXE Queryiale HCUACDEVentsischemes|Apes! DefeukiCCSelecl currerti(Defaut) SUCCESS 7 E 
49 REGMONENE Closeley — HCUVADpEventslSchemeslapos] DefautCCSelect) curent. SUCCESS — Key: DXÉ2BOCEO = 


Figura 8-1. Seguimiento realizado por Registry Monitor 
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El uso principal de este programa estriba en la capacidad que tiene para supervisar 
todos los accesos efectuados al registro; se suele utilizar para rastrear los mecanismos de 
protección que bien lean o guarden información en el registro. Entre ellos figuran, por 
ejemplo, los programas de duración limitada o con otro tipo de restricción que almacenan 
en el registro o cuándo se instalaron o cuántas veces cierta función se lleva utilizando, 


Algunos desarrolladores, al intentar ocultar (a los crackers) las definiciones que un 
programa realiza en el registro de Windows, utilizan áreas que normalmente no tienen ese 
cometido, como el espacio asignado al sistema, otros programas ya instalados, etc. El 
hecho de que Registry Monitor detecte con facilidad estas operaciones demuestra de nuevo 
la ingenuidad de algunos programadores. 


A continuación se mostrará el manejo de este programa y alguna de sus funciones 
mediante un sencillo ejemplo extraído del capítulo 2 sobre depuración donde se rastrean 
algunos valores del registro para detectar SoftICE: 


HKEY Key; 
BYTE VerDataBuffer[200],InstDataBuffer[200]; 
DWORD VerSize = 5,InstSize = 128; 


if 
(RegOpenKeyEx (HKEY_LOCAL_ MACHINE, “SoftwarelANuMegalASo£ftI 
CEM” ,NULL, KEY READ, Key) == ERROR_SUCCESS) 


// ¿hallada clave añadida por SoftICE? 
( 
RegQueryValueEx (Key, “Current 
Version” NULL, NULL, VerDataBuffer,8VerSize); 
// Versión de SoftICE 
RegQueryValueEx (Key, "InstallDir” NULL, NULL, 
InstDataBuffer, «€ InstSize); 
// Directorio de instalación de SoftICE 
MessageBox ( (const char*) InstDataBuffer, (const 
char*) VerDataBuffer,MB_0K); 


) 


else 
MessageBox ("SoftICE no detectado” ,NULL,MB_O0K) ; 


Arránquese Registry Monitor y a continuación el programa de detección de 
SoftICE. No se pulse todavía el botón para comenzar la detección. Obsérvese lo que 
Registry Monitor ya ha detectado. 


Un buen número de procesos, como el Explorador, interactúan casi constantemente 
con el registro dificultando cualquier búsqueda en el Registry Monitor. Afortunadamente 
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esta herramienta contiene un filtro que ahorra al usuario tener que buscar entre cientos, 
sino miles, de definiciones realizadas en el registro para encontrar las que esté buscando. 
Púlsese Ctrl+E para desactivar la supervisión, la herramienta dejará entonces de mostrar 
los accesos al registro realizados por los distintos procesos en ejecución. Sabidos los 
nombres de los procesos que acceden al registro, podrán definirse a la herramienta aquellos 
que se desean observar; e incluso si no se supieran tales nombres, queda la alternativa, 
bastante más larga, de excluir los demás procesos. Realizada la labor de búsqueda, se 
podrá observar el nombre del proceso bajo la columna “Process”. El proceso que detecta 
SoftICE se denomina RegisterSiCheck. Púlsese ahora Ctrl+L (o bien selecciónese 
Options — Filter...) para mostrar el cuadro de diálogo del filtrado. 


El 
Process Include(s): A] 
Process Exclude(s): TK Reset | 
Path Include(s): AA Cancel 

Path Exclude(s): O EN 

History Depth: pp 


IV Log Reads Y Log Success 


IV Log Wiites [4 Log Erors 


Figura 8-2. Cuadro de diálogo para realizar el filtrado 


En la anterior figura se muestra el cuadro de diálogo donde se definen los distintos 
criterios para realizar el filtrado de los procesos mostrados. Introdúzcase el nombre del 
proceso (RegisterSiCheck) en el campo “Include” y púlsese por último “Apply”. 


Vuélvase a activar la supervisión de Registry Monitor, suprimanse los procesos 
anteriores pulsando Ctrl+X y ejecútese el programa para detectar SoftICE de nuevo. Al 
incluir solamente los accesos al registro de las aplicaciones seleccionadas, la lista resulta 
mucho más corta y clara. A continuación púlsese el botón para arrancar la detección de 
SoftICE, Registry Monitor visualizará inmediatamente las líneas siguientes: 


RegistrSICheck. OpenKey HKLM ASoftware ANuMega ASoftIce Ae 


RegistrSICheck. QueryValue HKLM ASoftware AWuMega ASoftIce Current Version 
RegistrsIcheck. QueryValue  HKIM Software WMulega ASoftIce ACurrent Version 
RegistrsIcheck. QuerpValue  HKLM ISoftware WuMega ASoftIce VInstallpir 
Rogistrsicheck. Queryvalue  HKIM ASoftware MuMega WSoftIce MInstal1Dir 


Queda así al descubierto el intento de detectar SoftICE a través del registro. 
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FILE MONITOR 


[Trios Trrocosá —[eguost Tesh [rear Tote A 
14950 xl C:WINNTISystem321CorfigiSYSTEM SUCCESS Offset; 4096 Length: 512 
CWINNTISystem321ConfiSYSTEM SUCCESS. . 
CA WINNTiSystem3ziConfigiSYSTEM SUCCESS. 
C;NWINNTISystem321ConfigiSYSTEM. SUCCESS 
C:IWINNTISystem321Config| SYSTEM. SUCCESS. 
EAWINNTISystemd2|Configi5YSTEM SUCCESS 
C: DASD SUCCESS. Offset: 4096 Length; 4096 
E ¡AWINNTISystem32AConfigi SYSTEM SUCCESS Offset: O Length; 512 
S A WINNTSystemaziCorfigiSYSTEM. SUCCESS. 


€: DASD. SUCCESS — Offset: 4096 Lengih: 4096 
sl AMARO CO STE ALT SUCCESS 

SUCCESS — Offset: 4096 Length: 4096 
E ARNt COrhAASASTE ALT= SUCCESS — Offseti DLength: 512 
CAWINWTISystemB2lCorfiSYSTEM.ALT SUCCESS 
C:DASD SUCCESS — Ofíset: 40% Length: 4096 
CoIWINATISystem32ACorfig|SYSTEM.ALT — SUCCESS — Offset: 4096 Length: 51. 
CEIWIMATISystem32|CorfigiSYSTEM.ALT — SUCCESS — Offset: 3612160 Length: 
CAWINWTISystem32AConfigiSYSTEM.ALT — SICCESS — Offset: 4454400 Length: 


PISTA RIE. CAWINNTISystem3ZiConfigiSYSTEM.ALT — SUCCESS — Offseti 4546560 Length: . 
TRPZMOZVAITE CoWINNTASystemziCorfigiSYSTEM.ALT — SUCCESS — Offset: 4663296 Length: 
IP OFLUSH CAWINATISystem3ZiCorfigiSYSTEM.ALT — SUCCESS 

TRPLMI WRITE €: DASD SUCCESS — Offset: 409% Length: 4096 


CHWINNTISystem32IConfGISYSTEM.ALT — SUCCESS — Offset; OLength: 512 
CoWINNTISystem32iConfiiSYSTEM.ALT SUCCESS 


C:DASO, SUCCESS — Offset: 4096 Lema: 4096 

CilDocumerts and SettimslZemozius... SUCCESS Offset: OLengthi 4096 
IAP_MISET_INFORMATION —— CiDocuments and SettivgslZemoZipdas,.... SUCCESS PleEndofFielnformation 
JRP_MI_FILE SYSTEM,CONTROL — ColcrecinglFiemon SUCCESS — FSCIL_AS_NOLUME_MOU, 
IRP_JM)_CREATE CacradinglFieron|Flemon.exe SUCCESS — Altrbates; Any Oplors: .. 
FASTIO_QUERY_BASIC_INFO —— CilcracinglfiemoniFiemeniexe SUCCESS — Altrbates: A 
Rp WOLCLEANP ti ia Áned SUCCESS 
Tee _M_CLOSE CocraciinglFiemenirlemen,exe SUCCESS 
IRP_M_FILE_SYSTEM.CONTROL — Cicraclnglfienon SUCCESS — FSCIL_IS YOLUIME_MOW, 
RP MORANTE C:DASD SUCCESS — Offset: O Length: 4096 
IRP IN WRITE ps SUCCESS — Offset: D Lenglh: 4036 
IRPZO WRITE SUCCESS — Offset: O Length: 4096 
IRP_M_FULE, SYSTEM CONTROL Ncedlaegien SUCCESS _ FSCTL AS VOLUME MO, y 


Figura 8-3. La interfaz de usuario de File Monitor y de Registry Monitor resultan 
prácticamente idénticas 


Este otro programa también supervisa ciertas actividades de los procesos en 
ejecución. En este caso, los accesos a ficheros. File Monitor, al igual que el anterior 
programa, resulta útil para anular muchos tipos de protecciones. Puesto que, dejando al 
margen que se supervisa un tipo de actividad diferente, apenas existen diferencias entre 
este programa y Registry Monitor, sólo se incluirá aquí un ejemplo sencillo de su manejo; 
en este caso se buscará el nombre correcto de un fichero de claves de un programa 
protegido con este método. El código del programa es verdaderamente sencillo, tan sólo es 
una fracción de la posible protección que compruebe la presencia de un fichero con un 
nombre concreto. Como botón de muestra, puede resultar suficiente. 


HANDLE File = CreateFile (“key file.key 

GENERIC _] READ, FILE SHARE _READ,NULL,OPEN_: EXISTING, 

FILE ATTRIBUTE_NORMAL, NULL);  // obtención del manejador 

// del fichero 

if (File == INVALID HANDLE VALUE) 
( 

MessageBox (“Error: no hallado fichero de claves”, 

NULL, MB_0K) ; 

return; 


) 
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Como con el ejemplo del Registry Monitor, aplíquese un filtro al proceso 
correspondiente para facilitar la búsqueda. Supongamos que el proceso en cuestión se 
denomina FileChecker.exe. File Monitor mostrará lo siguiente nada más intentar 
comprobar la presencia del fichero: 


FilecCheck.exe  IRP_MJ_FILE SYSTEM_CONTROL path 


Tan sólo resta leer el nombre del fichero que se está buscando. 


“Result”, la segunda columna empezando por la derecha, mostrará el resultado de la 
operación realizada. Si el fichero buscado no llegara a localizarse, la columna mostraría el 
mensaje “FILE NOT FOUND”, en caso contrario: “SUCCESS”. 


R!SC'S PROCESS PATCHER 


Este programa genera cargadores rápidos, por ello será especialmente apreciado por 
quienes no les guste programar Su propio cargador o bien carezcan de experiencia para 
realizarlo. Funciona mediante varios ficheros de mandatos que se emplean para generar el 
cargador. 


[E] a2prz43.1pp 
(E) crackme.rpp 
Histone. 


a Kind2_cd182_nofmw.rpp 


Plocha heolite20,rpp 


neotrace122.rpp 
a 13] Pecrypt102.rpp 


O JE) play the game.rpp 


Název souboru: I +] 
Soubo pu [APP SCA . 


5 Dieyiitjen pio Blení 


Figura 8-4. No existen ni cuadros de diálogo ni menús en este programa 


Basta tan sólo con arrancar el programa y elegir el fichero de mandatos. Véase la 
lista de mandatos y los dos ejemplos siguientes. 
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5 


Ficheros de mandatos 


:— indica comentario. Queda ignorado todo lo que siga hasta la línea siguiente. 
F — nombre del fichero o proceso que ejecutará o modificará el cargador. 
O — nombre del fichero cargador. 


P — define parámetros necesarios para realizar modificaciones de partes de la 
memoria donde se carga el programa. Se aplica la sintaxis siguiente: 
ADDRESS/SEARCH/REPLACE, que significa: dirección de memoria donde 
se realizarán las modificaciones + carácter “/” + bytes en esta dirección (para 
verificar la validez, útil, por ejemplo, al comprobar si el fichero se ha 
descodificado) separados por comas + otro carácter “/” + bytes con las 
modificaciones. 


T — número de intentos en modificar la memoria de un proceso. Resulta útil, 
por ejemplo, al alterar programas protegidos por compresores o codificadores 
PE, donde no se pueden practicar las modificaciones antes de que el fichero 
sea descodificado o descomprimido. 


R — significa “proseguir hilo” (en inglés, “Resume Thread”), esto es, rearrancar 
el proceso con el estado “suspended”. 


: carácter empleado al final de cada mandato. 


$ — indica el final de un fichero de mandatos. 
He aquí un ejemplo de fichero de mandatos: 


¡CiA 's Trial CrackMe 0.99b 
¡splash screen crack by R!SC april 1999 


F=crackme.exe: ; nombre del fichero que va a 
¡ejecutarse y modificarse 
O=crack_the crackme.exe: ; nombre del fichero de 
¡; Carga 
P=00465F18/83/C03: ¡; modificación del fichero en memoria 
¡; que efectuará el cargador 
; incluirá la instrucción RET al 
; principio de una rutina que 
; muestre la imagen de bienvenida 
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¿RISC 's cdcheck crackme crack, by R!SC — june 1999 


F=play the game.exe: ; nombre del fichero que va a 
; ejecutarse y modificarse 


O=crack checkcd.exe: ; nombre del fichero de carga 
P=004014B2/74,02/72,00: ¡anti-SoftICE 
P=00401202/85,C0/B0,01: ¡¿se ha insertado un disco? 
P=0040121C/75,5D/75,00: ¡ verificación del nombre del 
; disco 
P=00401517/75,43/75,00: ¡ comprobación de integridad 
¡ (checksum) 


$ 


Una vez definido el fichero sólo queda ejecutar el programa y elegir el fichero de 
mandatos, ya se habrá creado el cargador. 


THE CUSTOMISER 


Obsérvese la siguiente imagen de la calculadora de Windows: 


fl Calculator 


Inv CiHy» 6d] e 1 


a 00a ao 
» [9] [m]) E Xox 
E + 
v2][1] Lo) [a JLo JLo JLo 


Figura 8-5. Imposible efectuar operaciones con esta calculadora 


Bien puede apreciarse que esta calculadora no es como las demás. Ha sido 
modificada por uno de los muchos editores de recursos. Aquí se describirá uno de ellos. 
Denominado “The Customiser”, es probablemente el editor de recursos en tiempo de 
ejecución más conocido. 
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Este programa permite trabajar y manipular todas las ventanas que estén activas en 
un momento dado en Windows. No importa que sean cuadros de diálogo, ventanas, 
botones, campos para marcar opciones o cualquier otro control. Todo se puede editar; este 
programa permite hacer al usuario lo que quiera. Se pueden modificar los textos de los 
controles y ventanas, activarlos o desactivarlos, desplazarlos, mostrarlos o ocultarlos, y 
muchas más cosas. Las modificaciones podrán entonces guardarse en aplicaciones, no 
directamente al programa original como sucede con los editores de recursos normales (no 
en tiempo de ejecución) sino sólo en memoria; The Customiser aplicará los cambios 
siempre que se arranquen dichos programas. 


Esta herramienta ha llegado a convertirse en una pesadilla para muchos 
programadores que basan la protección de sus programas en un par de controles 
desactivados. Existen muchas maneras de activarlos; sin embargo, este método está al 
alcance incluso de todos los principiantes. Por esta razón se ha prevenido al lector varias 
veces contra los problemas relativos a este tipo de “protección” procurando orientarle a 
otros tipos de protección contra estos programas. 


El uso de The Customiser resulta verdaderamente sencillo. Tras su arranque 
mostrará el siguiente cuadro de diálogo: 


Fig The Customiser 


JY. Customiser Enabled 


TT Stay On Top 


Figura 8-6. Apenas existen opciones en el cuadro de diálogo inicial de T) he 
Customiser 


Las opciones del cuadro de diálogo inicial de The Customiser tan sólo permiten 
activarlo e indicar si debe permanecer siempre visible. Tras pulsar el botón “Edit 
Window”, The Customiser mostrará el entorno de trabajo: 
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€ Enable Show 
€ Disable € Hide ] 


Use the 1ohtmouse button lo brina up he Configuration mena 
Class: ¡Button 2 


: Test: JOR z a 
Parent Class: 1832770 23 


Parent Text: [The Customiser Configuration Screen a 


Handle: Dx0132 — Top: 444 
(522,417) ld: E 


Figura 8-7. Opciones de la ventana de configuración 


Al elegir una de las opciones de control (“Enable”, “Show”, etc.) y pulsar el botón 
“On”, variará el curso del ratón y tras señalar el sitio elegido, se llevará a cabo la acción 
anterior. Al pulsar el botón “OfP” no se podrá indicar ninguna ventana más. 


Existen muchas otras funciones recogidas en las pestañas de otros menús: 
desplazamiento de objetos, modificaciones de texto, envío de mensajes Windows, etc. 
todas las pestañas anteriores contienen un menú para guardar las modificaciones. 


Y Save Action Window must match current settings of: 
(Always Y Parent window T Original Text 
€C This Session Only | Y Resourceld JW Class Name 


Figura 8-8. Cuadro de diálogo para “guardar” modificaciones hechas con The 
Customiser 


Tras seleccionar la opción “Save Action”, debe indicarse cómo se guardarán las 
modificaciones (con “Always” las modificaciones se cargarán siempre que se arranque y 
active The Customiser; con “This Session Only”, los cambios sólo se aplicarán en esta 
sesión) y qué método de verificación se empleará para verificar la aplicación y la ventana 
en la que deban realizarse las modificaciones. No se olvide que éstas nunca se guardan 
directamente en el programa. The Customiser las aplica en memoria siempre que se 
arranque y active. Si se arrancase la aplicación sin que estuviese The Customiser activo, no 
tendría lugar ninguna modificación. 
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En el capítulo siguiente se incluirá un ejemplo de uso práctico de The Customiser. 
Tan sencillo resulta este programa que no debería suponer ningún obstáculo para nadie. 


Naturalmente, The Customiser y programas semejantes no representan el único 
modo de, por ejemplo, activar y desactivar botones. Otro método muy común consiste en 
el uso de editores de recursos ordinarios (no en tiempo de ejecución), éstos sí guardan las 
modificaciones directamente en el programa. 


Aunque útil, la enumeración aquí hecha no constituye ni de lejos una lista completa 
de los programas que utilizan los crackers. En el CD adjunto figuran varios programas de 
este tipo y pueden encontrarse muchos más en Internet. 


CAPÍTULO 9 


CRACKING DE ENTRENAMIENTO 


Una vez leídos los capítulos anteriores, el lector se encuentra en disposición de 
practicar el “cracking”. Como bien dice la consigna, “la mejor defensa es un buen ataque”. 
Así que, en sintonía con tal principio, ¿qué mejor forma de comprobar la seguridad de una 
protección que atacara? Éste será el objetivo precisamente de este capítulo. Mediante 
programas de entrenamiento, denominados “crackmes”, diseñados con fines pedagógicos, 
el lector podrá aprender los fundamentos de las técnicas más actualizadas que los crackers 
utilizan hoy en día para así aplicarlas con sus programas y comprobar su resistencia. 


Se han elegido crackmes deliberadamente poco complicados para que se pueda 
apreciar rápidamente al menos los fundamentos del cracking como un todo. No habrán de 
considerarse estos ejemplos como un tipo de protección específica. Por el contrario, en la 
mayoría de los casos, muchos de los autores de crackmes cometen ciertos errores adrede 
para que hasta las personas sin experiencia puedan acceder a ellos. En otras ocasiones, se 
destacan deliberadamente en este entrenamiento los mismos errores pero de las 
protecciones actuales que sufren algunos programas con objeto de mostrar sus puntos 
débiles. 


De estar interesado en ejemplos más complicados que ilustren las muchas técnicas y 
trucos de protección originales y con frecuencia excelentes, acúdase al CD adjunto y, por 
supuesto, a Internet. 
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CRUEHEAD - CRACKME V1.0 


Con este ejemplo relativamente simple se ilustrará un mecanismo de protección 
basado en la introducción de un nombre a partir del cual queda generado el número de 
serie correcto. El algoritmo emplea una codificación muy sencilla basada en la función 
lógica XOR. A continuación se examina con detalle el procedimiento para demostrar con 
exactitud cómo descubrir la combinación correcta de número y nombre. 


Arránquese el programa y elíjase el campo “Register” del menú “Help”. En el 
cuadro de diálogo resultante rellénense en los campos “Name” y “Serial” con cualquiera 
valor. Se puede utilizar ZemoZ como valor de “Name”. 


Dx 


Figura 9-1. Cuadro de diálogo con información estrictamente confidencial 


Púlsese Ctrl+D para mostrar SoftiCE. Ha de considerarse detenidamente cómo 
aproximarse lo más posible al algoritmo de protección. Un punto de entrada ideal al 
programa podría ser alguna llamada a una función API empleada para obtener información 
que se le suministrara —en nuestro caso, los dos campos “Name” y “Serial” —. Se prueba 
con la función API GetD1gItemTextA. 


Defínase el punto de corte bpx a esta función API en SoftICE de la manera 
siguiente: 


bpx GetDlgltemTextA 


Vuélvase al programa (CtrHD) y púlsese el botón OK, SoftICE aparecerá 
inmediatamente al ser invocada la función API GetDl1gItemTextA contra la que se 
definió el punto de corte. Ahora se sabe que el programa está leyendo el nombre y número 
introducidos y que por tanto invocará esta función API dos veces —la primera para leer el 
ítem “Name”, y la segunda para leer el ítem “Serial”—. Púlsese FS (o Ctri+D) y SoftICE 
se detendrá en la segunda invocación a la función API. Al pulsar la tecla F1 1, se obtendrá 
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el código que invocó esta función, esto es, el código de nuestro programa, Bien es cierto 
que no sirve de mucha ayuda conocer el lugar desde el que se invocó la función API: habrá 
por tanto que pulsar F12 un par de veces para conocer el sitio desde el que se procesan los 
datos leídos. Púlsese F12 tantas veces como sean necesarias para retroceder al código del 
programa (se atravesará por un par de librerías). Éste será el código resultante: 


:0040121E call USER32!DialogBoxParamA 

:00401223 cmp eax, 00000000 

:00401226 je 004011E6 

:00401228 push 0040218E <-- nombre introducido - 

Name 

:0040122D call 0040137E <-- obtención del resultado 
de la operación XOR a 

partir del nombre 


introducido 
:00401232 push eax <-- ¿guardando el resultado XOR 
del nombre 
:00401233 push 0040217E <-- «número introducido - 
Serial 


:00401238 call 004013D8 <-- cálculo del valor 
correcto XOR según el 
nombre introducido 


:0040123D add esp, 04 <-- alineamiento de pila 

:00401240 pop eax 

:00401241 cmp eax, ebx <-- ¿valores idénticos?¿número 
de serie introducido 
correcto? 


:00401243 jz 0040124C  <-- bifurcación = número 
introducido correcto 


Si se desea aceptar también una pareja de nombre y número incorrectos, deberá 
forzarse a la instrucción JZ en la dirección 00401243 a bifurcar. Con SoftICE se puede 
realizar esta operación acudiendo a la instrucción (pulsando repetidamente Fl0) y 
escribiendo el mandato siguiente: 


ríl z 


Este mandato cambiará el resultado de la anterior instrucción CMP a su contrario 
(modificando el indicador cero), lo que invertirá la lógica del algoritmo. 


Ahora bien, se pretende descubrir el número correcto correspondiente al nombre 
introducido. Ello exige examinar las llamadas en las direcciones 0040137E y 004013D8. 
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:0040137E 
:00401382 
:00401383 
:00401385 


:00401387 
:00401389 


:0040138B 


:0040138D 


:0040138F 
| :00401391 
:00401392 


:00401394 
:00401399 


:0040139A 


una instrucción JA 


función: 


:004013C2 
:004013C4 
:004013C6 


:004013C8 


mov esi, [esp+04] <-- nombre introducido 
push esi <-- guardando en pila 
mov al, [lesi] <-- ESI = puntero al nombre 
test al,al <-- ¿procesada la última letra 
del nombre? 
jz 0040139C <-- en caso afirmativo, final 
cmp al, 41 <-- Comparación con el valor 
41h, i.e. A 
jb 004013AC <-- bifurcación si El valor es 
menor a A 
cmp al,5A <-- Comparación con el valor 
5Ah, 1.e. Z 
jae 00401394 <-- bifurcación, sia el 
valor fuera mayor o igual a Z 
inc esi <-- incremento del puntero a la 
letra procesada del nombre 
jmp 00401383 <-- repitiendo, proceso del 


nombre completo 
call 004013D2 <-- valor mayor o igual a Z 


inc esi <-- incremento del puntero a la 
letra procesada del nombre 
jmp 00401383 <-- repitiendo, proceso del 


nombre completo 


Esta parte del código comprueba que todas las letras vayan en mayúsculas (y 
también que el nombre contenga caracteres representados por un valor inferior al que 
representa la letra A). En caso contrario, los caracteres en minúsculas se convierten en 
mayúsculas invocando una función en la dirección 00401394. Esta función contiene la 
| instrucción SUB AL, 20h. 


Resulta muy probable que se produzca un error en el programa (se podría esperar 


donde figura una instrucción JAE en la dirección 0040138F) al 


procesarse la letra “Z” y transformarse en el carácter *:”. El valor SAh se transforma en 
3Ah. Estas precisiones son pertinentes dado el nombre de registro elegido. 


Estamos situados aún en la instrucción CALL 0040137E. Otra instrucción CALL 
figura en la dirección 0040139D — CALL 004013C2. Obsérvese lo que pasa con esta 


xor edi,edi <-- EDI=0 

xor ebx,ebx <-= EBX = 0 

mov bl,byte ptr [esi] <-- ESI = puntero al 
nombre 

test bl,bl <-- ¿procesada la última letra 


del nombre? 
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:004013CA jz 004013D1 <-- en caso afirmativo, final 
:004013CC add edi, ebx <-- suma de los valores de las 
letras del nombre 
:004013CE inc esi <-- desplazamiento del puntero a 
la siguiente letra del nombre 
:004013CF jmp 004013C6 <-- próxima letra 


Esta función añade los valores numéricos de todas las letras y guarda el resultado en 
el registro EDI. El nombre introducido ha quedado alterado debido a la rutina de 
transformación en letras mayúsculas de “ZemoZ” a “«EMO;”. En este caso la suma de los 
caracteres del nombre será la siguiente: 


:EMO:=3Ah +45h +4Dh +4Fh +3Ah =155h 
A este valor se le aplica el operador XOR con el valor 5678h. 


:004013A2 xor edi,00005678 <-- XOR 
:004013A8 mov eax, edi <-- el resultado se guarda en 
el registro EAX 


En este caso, el resultado de esta operación será 572Dh. El valor se almacenará 
entonces en el registro EAX y se comparará con el valor del registro EBX en la dirección 
00401241. Este registro se completará con el segundo CALL en la dirección 00401238 - 
CALL 004013D8: 


:004013D8 xor eax, eax <-- FEAX = 
:004013DA xor edi,edi <-- EDI = 
:004013DC xor ebx,ebx <-- EBX = 
:004013DE mov esi, [esp+04] <-- número introducido 
:004013E2 mov al, 0A <-- AL=10 

:004013E4 mov bl1,byte ptr [esi] <-- ESI = puntero al 
número introducido 


ooo 


:004013E6 test bl1,bl <-- ¿procesado el último 
carácter del número? 
:004013E8 jz 004013F5 <-- en caso afirmativo, final 


:004013EA sub b1,30 
:004013ED imul edi,eax 
:004013F0 add edi, ebx <-- ¿guardando en EDI 
:004013F2 inc esi <-- desplazamiento del puntero al 
| siguiente carácter del número 
:004013F3 jmp 004013E2 <-- proceso del carácter 
siguiente del número 
introducido 
| :004013F5 xor edi,00001234 <-- ¡¡aquí está!! 
:004013FB mov ebx,edi <-- guardando EDI en EBX (para 
la siguiente comparación) 
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Este código sólo convertirá el número introducido en formato hexadecimal. No 
obstante, la información principal podrá hallarse en la dirección 004013FS. Al número 
convertido se le aplica el operador XOR con el valor 001234h y el resultado se almacena 
en el registro EBX. 


Conviene recordar la instrucción en la dirección 004012241 - CMP._ EAX, BPX, 
quien decide la idoneidad del número de registro introducido, En este punto ya se sabe el 
valor correcto del registro EAX a partir de la CALL en la dirección 0040122D, El registro 
EBX será igual al número de serie introducido en formato hexadecimal al aplicarle la 
operación XOR con el valor 00001234h. Los registros EAX y EBX deberán ser iguales, lo 
que significa que la operación EAX XOR 00001234h coincidirá con el número de serie 
correcto. 


EAX (en este caso) = 572Dh XOR 00001234h = 4519h = 17689 


Por lo tanto, el número de serie correcto para el nombre ZemoZ será 17689, 


CRUEHEAD - CRACKME V2.0 


Oiradkme v2.0 
Ale Help 


Enter Password 


Figura 9-2. Introdúzcase la contraseña correcta 


Este ejemplo resulta prácticamente idéntico al anterior, en este caso basta con 
introducir la contraseña en vez de la combinación de nombre y número de serie. Al igual 
que en el ejemplo anterior, aquí también se emplea la función lógica XOR en combinación 
con dos instrucciones CALL básicas. Se comparan al final los resultados de ambas 
instrucciones. 
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La estructura y construcción de este ejemplo es absolutamente idéntica a la anterior. 
La rutina principal del programa resulta muy semejante: 


:00401228 push 0040217E <-- contraseña introducida 

:0040122D call 00401365 <-- idéntico al ejemplo 
anterior 

:00401232 push 0040217E <-- guardando el resultado 
de XOR con la contraseña 
introducida 

:00401237 call 004013B8 <-- comparación de 
resultados 

:0040123C add esp, 04 

:0040123F test cl,cl <-- ¿valores iguales? 

:00401241 jz 0040124A  <-- en caso afirmativo, 

victoria 


De la misma manera, la primera instrucción CALL convertirá a mayúsculas todos 
los caracteres que no lo sean y aplicará el operador XOR a su suma con un valor particular, 
En este caso el valor es distinto, concretamente “Messing in bytes”, esto es, 4D 65 73 73 
69 6E 67 5F 69 6E 5F 62 79 74 65 73h. El resultado de esta operación se guardará en la 
dirección 0040217E, muy fácil de obtener aun sin examinar las funciones individuales. 


Al detenerse en la segunda instrucción CALL, se podrá observar que el resultado de 
la anterior operación se compara con el valor 1F 2C 37 36 3B 3D 28 19 3D 26 1A 31 2D 
3B 37 3Eh. Queda claro que al aplicar el operador XOR a este valor con la clave 
codificada de “Messing in bytes”, se obtendrá la contraseña correcta, 


AD 65 73 73 69 GE 67 5F 69 GE 5F 62 79 74 65 73h XOR 
1F 20 37 36 3B 3D 28 19 3D 26 1A 31 2D 3B 37 3Eh 
=RIDERSOFTHESTORM. 


CRUEHEAD - CRACKME V3.0 


Figura 9-3. Al menos puede saberse quién violó el programa 
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El tercer y último ejemplo de Cruehead emplea una protección basada en un fichero 
clave. 


Como punto de entrada oportuno al programa, se utilizará la función API 
CreateFileA (con objeto de acceder al fichero, esto es, obtener su manejador). El 
programa buscará el fichero clave nada más arrancar, lo que exigirá habilitar SoftICE antes 
de arrancar el programa e introducir el siguiente mandato para establecer el punto de corte 
a la función anteriormente mencionada: 


bpx CreateFileA 


Tras arrancar el programa, SoftICE se mostrará. Púlsese F11 para acceder al código 
del programa. Se observará el código siguiente: 


:00401028 push 004020D7 

:0040102D call KERNEL32!CreateFileA 

:00401032 cmp eax,-01 <-- ¿fichero hallado? 
:00401035 jnz 00401043 <-- bifurcación = sí 


Los parámetros de la función se almacenan en la pila en orden inverso, esto es, el 
último parámetro guardado será el primer parámetro de la función. El primer parámetro de 
la función CreateFileA será el nombre del fichero. La última instrucción PUSH, por lo 
tanto, señalará el nombre del fichero que se esté abriendo. Introdúzcase el mandato 
siguiente: 


d 004020D7 


El nombre del fichero —CRACKME3.KEY— figurará en la ventana de datos. 
Créese un fichero del mismo nombre y continúese el proceso: 


:00401043 mov [004020F5] ,eax <-- Guardando el 
manejador del fichero 

:00401048 mov eax,00000012 <-- número de bytes para 
leer del fichero 

:0040104D mov ebx,00402008 <-- buffer de datos 

:00401052 push 00 <-- ¡parámetros de la función API 

ReadFile 

:00401054 push 004021A0 

:00401059 push eax 

:0040105A push ebx 

:0040105B push dword ptr [004020F5] 

:00401061 call KERNEL32!ReadFile <-- invocación de la 
función API ReadFile 
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:00401066 cmp dword ptr [004021A0],12 <-- ¿12h bytes 
leídos? 
:0040106D jnz 00401037 <-- en caso contrario, el 
fichero no tiene el tamaño 
correcto 


El fichero se cargará en memoria en la dirección 00402008 (EBX) mediante la 
función API ReadFile para luego comprobar su tamaño. Resulta obvio a partir del 
código que el fichero debe tener el tamaño de 12h (18 bytes). Puesto que el fichero se 
editará repetidas veces en el futuro, resulta más apropiado emplear un editor hexadecimal. 


Obsérvese ahora la siguiente instrucción CALL: CALL 0 0401311: 


:00401311 xor ecx,ecx <--= ECX=0 

:00401313 xor eax,eax <-- EAX = 0 

:00401315 mov esi, [esp+04] <-- HESI señala al 
principio del buffer 
de datos 


:00401319 mov bl,41 <-- BL= 41h 
:0040131B mov al, [esi] <-- AL = byte del fichero 
crackme3 .key 


:0040131D xor al,bl <-- XOR (descodificación) 
:0040131F mov [esil,al <-- guardando el resultado en 
el buffer 
:00401321 inc esi <-- desplazamiento del puntero al 
byte siguiente del fichero 
:00401322 inc bl <-- incrementando BL 
:00401324 ada dword ptr [004020F9],eax  <-- sencilla 
comprobación 
de integridad 
:0040132A cmp al, 00 <-- ¿es nulo el resultado de la 
descodificación? 
:0040132C jz 00401335 <-- bifurcación = final de la 
descodificación 


:0040132E inc cl <-- Ccl++ 

:00401330 cmp bl,4F <-- ¿BL = 4Fh? (4Fh - 41h = 14 
bytes). 

:00401333 jnz 0040131B <-- bucle 

:00401335 mov [00402149] ,ecx 


Ésta es una sencilla rutina de decodificación, que aplica sucesivamente XORs a 
cada byte del fichero clave (nombre de usuario codificado) con un valor progresivamente 
mayor, comenzando en 41h y terminando en 4Fh. Lo que obviamente significa que el 
tamaño máximo de la parte del fichero clave descodificado será 4Fh-41h = 14 bytes. La 


278 CRACKING SIN SECRETOS CG RA-MA 


descodificación finalizará tan pronto como el resultado de la operación XOR sea cero o el 
valor de BL igual a 4Fh. 


Para el nombre de usuario ZemoZ, la operación realizada será la siguiente: 
ZemoZ=5A 65 6D 6F S5Ah 
XOR 41 42 43 44 45h 
Result 1B 27 2E 2B 1Fh 


Al rehusar utilizar los restantes bytes libres (14 — 5 bytes utilizados = 9 bytes) para 
guardar el nombre de usuario, resulta obligatorio que sea cero el resultado de la operación 
XOR. Al aplicar XOR con dos valores idénticos se obtiene dicho resultado. Al seguir al 
último valor utilizado 45h el valor 46h, será preciso añadir este último detrás del nombre 
de usuario. 


El código del programa resultante: 


:00401079 xor dword ptr [004020F9],12345678 ge 
comprobación XOR 12345678h 

:00401083 add esp, 4 

:00401086 push 00402008 

:0040108B call 0040133C <-- FEAX = últimos cuatro 

bytes del buffer 

:00401090 add esp, 4 


:00401093 cmp eax, [004020F9] <-- ¿comparación - EAX 
= comprobación de 
integridad? 

:00401099 sete al <-- si los valores fueran iguales, 


entonces AL = 1 

:0040109C push eax 

:0040109D test al,al <-- siAL=1mnmo se ejecuta la 

bifurcación siguiente 

:0040109F jz 00401037 <-- bifurcación = no se ha 
violado con éxito el 

programa 


Este código leerá los últimos cuatro bytes del fichero clave a partir del buffer y los 
comparará con el valor de la comprobación de integridad tras aplicarle la operación XOR 
con 12345678h. Por lo tanto, si aplicamos la operación XOR al valor de comprobación de 
integridad del nombre de usuario introducido con el valor 12345678h, se obtendrá el valor 
correcto de los últimos cuatro bytes: 
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Comprobación de integridad para el nombre de usuario ZemoZ: 


sAh +65h +6Dh +6Fh +5Ah =1F5h XOR 12345678h =1234578Dh 

Resulta necesario escribir estos bytes en orden inverso (tras haberse obtenido del 
registro EAX, es preciso leerlos en el orden correcto). El fichero clave completo para el 
usuario ZemoZ será el siguiente: 


00000000:1B 27 2E 2B-1F 46 00 00-00 00 00 00-00 00 8D 57 


00000010:34 12 


COSH - CRACKME1 


[w” Crackmel - By CoSH 


Check for ED 


Figura 9-4. No hay muchos botones donde elegir 


En este ejemplo clásico se utiliza la típica protección basada en la comprobación del 
CD. 


En este contexto, la función API más conocida y empleada es GetDriveTypea,. 
Destínese a esta función un punto de corte mediante el mandato bpx GetDriveTypeA 
y púlsese entonces el botón “Check for CD”. SoftICE mostrará lo siguiente: 


:00401349 call KERNEL32!GetDriveTypeA 
:0040134F cmp eax, 03 <-- ¿DRIVE_FIXED? 
:00401352 jz 00401392 <-- en caso afirmativo, probar 
con otro disco 
:00401354 lea eax, lebp-18] 
:00401357 push 00403058 
:0040135C push eax 
:0040135D lea eax, [ebp-20] 
| :00401360 push eax 
:00401361 call 00401688 
:00401366 mov eax, [eax] 
:00401368 push ebx 
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:00401369 push 
:0040136A push 
:0040136B push 
:0040136C push 
:0040136E push 
:00401373 push 
:00401374 call 


:0040137A cmp eax, -01 <-- 


ebx 

ebx 

ebx 

(0j1b 

80000000 

eax <-- CD _CHECK.DAT 

KERNEL32 !CreateFileA <-- ¡interesante 
¿fichero hallado? 


:0040137D lea ecx, [ebp-20] 


:00401380 setz 


:00401384 call 


:00401389 cmp [ebp-0D],bl <-- 
:0040138C jz 00401485 gar 


byte ptr [ebp-0D] <-- si se detectó 
el fichero, 
entonces [EBP-0Dh] = O 
0040169A 
¿[EBP-0Dh] = 0? 
bifurcación = comprobación 
de CD anulada 


En este caso, la función GetDriveTypeA se utiliza para detectar el primer disco 
fijo que no tenga el atributo DRIVE_FIXED —como el CD-ROM (el parámetro de la 
función que indica el disco sobre el que se realiza la comprobación cambia 
continuamente) —. A continuación, la función API CreateFileA intenta abrir el fichero 
CD_CHECK.DAT desde el disco, si no lo encontrara (EAX=-1), se mostraría un mensaje 


de error. 


Figura 9-5. Aunque se haya fracasado se puede intentar de nuevo 


La estructura del algoritmo es bastante típica y muy semejante a muchas 
comprobaciones de CD empleadas sobre todo en juegos. Basta con cambiar JZ 
00401485 en la dirección 0040138C a JMP. El fichero se habrá así “localizado” y 
aparecerá un mensaje informando de que esta protección se ha violado correctamente. 


Figura 9-6. Mensaje de felicitación 
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Con un desensamblador todo queda más claro aún. Se puede observar en la lista de 
referencias de caracteres cómo la función API GetDriveTypeA va comprobando 
progresivamente todas las letras de los discos. 


MEXELITE - CRACKME 4.0 


Nada más arrancar, aparecerá el siguiente cuadro de diálogo: 


Figura 9-7. Basta con ver este cuadro de diálogo para saber el tipo de protección 
empleada en este programa 


Salta a la vista el tipo de protección que aquí se emplea: una combinación de 
nombre y número de serie. Introdúzcase cualquier nombre (que tenga al menos seis 
caracteres) y cualquier número, y definanse a continuación puntos de corte de sobra 
conocidos: GetDlgItemTextA y GetWindowTextA. Pronto se descubrirá que 
ninguno de los dos funciona. Obsérvese el programa con más detalle. El programa resulta 
bastante largo y las bien conocidas funciones API para obtener los contenidos de los 
campos del cuadro de diálogo no funcionan (tampoco funcionará aquí la función 
MessageBoxA)... Se habrá codificado el programa en Delphi. 


Es de sobra conocido que los programas codificados en Delphi no emplean las 
funciones API GetDlglItemTextA y GetWindowTextA para obtener los contenidos 
de los elementos de control; por lo tanto, la siguiente posible solución sea establecer un 
punto de corte en la función API Hmemcpy (o bien emplear un desensamblador: se 
descubrirá la ubicación del algoritmo de comprobación a partir de la referencia de 
caracteres fácilmente). Defínase un punto de corte a esta función, cuando aparezca 
SoftICE, púlsese FS para leer el contenido del segundo campo (tanto el nombre como el 
número introducidos deben leerse) y deshabilítese el punto de corte. 


Se obtendrá el código del programa pulsando un par de veces F12, o para ser más 
precisos, a la derecha de la sección del código, donde se compara el número de serie 
introducido con el correcto. 
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:0042DCA5 
:0042DCAA 
:0042DCAD 
:0042DCB2 


:0042DCB7 


:0042DCBC 


:0042DCC2 


:0042DCC4 
:0042DCC6 
:0042DCCD 
:0042DCCF 
:0042DCD4 
:0042DCD9 


Aunque aquí 


call 00414228 


mov eax, [ebp-04] 
call 004065A8 
mov [0042F760] ,eax <-- guardando el número 
introducido 
mov eax, [0042F758] <-- FEAX = número de 
serie correcto 
cmp eax, [0042F760] <-- Comparación entre 
el número de serie 
correcto y el 
introducido 
jnz 0042DCDB <-- bifurcación = combinación 
incorrecta de nombre y/o 
número 
push 00 
mov cx, [0042DD1C] 
mov dl, 02 
mov eax, 0042DDA0 
call 0042CE40 
jmp 0042DCFO <-- gracias por registrarse 


no se pretenda, resulta fácil forzar al programa a aceptar también 


combinaciones incorrectas de nombre y número. Sin embargo, este procedimiento hallará 
un número de serie válido según el nombre introducido. El nombre empleado en este caso 
será “Mr.ZemoZ”. A continuación se accederá a la dirección 0042DCBC donde se 
compara el número de serie correcto (en el registro EAX) con el número introducido para 
mostrar el contenido del registro EAX: 


? eax 


Se mostrará la siguiente información (válida para el nombre dado): 


D67637DC 


3598071772 (-696895524) 


De manera que el número de serie correcto es 696895524, 


IMMORTAL DESCENDANTS - CRACKME 8 


Este excelente ejemplo codificado con Visual Basic 6.0 contiene muchos tipos de 
protecciones. Aquí sólo se estudiarán algunas de ellas, 
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Crackme Challenge — 


Check Key 


 Cripp! 


Figura 9-8. Diferentes tipos de protección 


Lo primero que salta a la vista nada más arrancar el programa es una ventana de 
advertencia (en inglés, “NAG screen”). Se puede comenzar el cracking intentando 


suprimirla. 


1D Crackme Y8.0 By Whi2zKiD: 


U p This Prograrn is NOT registered, Please Register!! 


Figura 9-9. Ventana de advertencia que se pretende suprimir 


En primer lugar, utilícese el cargador de símbolos para cargar las exportaciones de 
la librería de Visual Basic 6.0 —msvbvm60.dll (File->Load Exports..->file)—. Ahora sí se 
podrán definir puntos de corte a las diferentes funciones de esta librería. 
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Como ya se mencionó anteriormente, la función rtcMsgBox sí suele utilizar con 
Visual Basic para mostrar MessageBox. La definición del punto de corte a esta función 
será: 


bpx msvbvm60!rtemsgbox 


SoftICE aparecerá nada más arrancar el programa. Púlsese F11l para volver al 
código del programa que invocó esta función. Aparecerá MessageBox, pulsando el botón 
“OK” se volverá a SoftICE. 


:0040FDDA call [MSVBVM60!rteMsgBox] 
:0040FDEO lea ecx,[ebp-1C] 


A partir de aquí, con aplicar la instrucción NOP a CALL (sobrescríbase la 
instrucción CALL con NOP tantas veces como sea preciso, 6 NOPs puesto que CALL 


tiene una longitud de 6 bytes), será suficiente para suprimir la molesta ventana de 
advertencia al principio de programa. 


Se examinarán a continuación tareas individuales. 


Easy Serial 


Al ser ésta una sencilla protección basada en un número de serie, se intentará definir 
el punto de corte a la bien conocida función empleada para comparar secuencias de 
caracteres en Visual Basic, vbastremp: 


bpx msvbvm60!  vbastrcmp 


Introdúzcase cualquier número de serie y púlsese el botón “Check Key”. Se podrá 
observar el siguiente código en SoftICE: 


:0040E932 push eax <-- parámetro de la función - 
número introducido 
:0040E933 push 0040BABO <-- ¡parámetro de la función 


- número correcto 
:0040E938 call [MSVBVM60!  vbaStrCmp] <-- invocación 
de la función 
de comparación 
:0040E93E mov esi,eax 


Así se puede comprobar lo potentes que son algunas funciones de comparación en 
Visual Basic: calcular el número correcto constituye una cuestión de segundos. En este 
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caso, la función vbastYcmp, toma las dos secuencias de caracteres comparados como 
parámetros. 


De este modo, si se muestran los parámetros de la función, no sólo se podrá ver el 
número introducido sino también el número de serie correcto. 


ad eax mostrará sólo el número introducido; sin embargo, antes será necesario 
definir el punto de corte antes de invocar a la función ya que ésta modifica el valor del 
registro EAX. 


A 0040BABO mostrará el número de serie correcto. 


Los números siguientes aparecerán en la ventana de datos: 


2.3.7.8.4.6.2.8. 
3.5.6.2... 7... 

Éste es el número de serie correcto en formato extenso. Éste es el formato empleado 
en todos los programas creados con Visual Basic: el desarrollador tendrá que 
acostumbrarse a él. Ignórense los espacios en blanco entre los números. El valor correcto 
es 23784628356267. 


Ha resultado muy sencillo. Lo mejor de todo ello es que muchos otros programas 
utilizan exactamente el mismo método para comparar números de registro; el lector se 
sorprendería por la cantidad de programas que se puede violar de esta manera tan simple. 


Harder Serial 


No hay razón alguna que justifique denominar a este método “Harder Serial” (en 
castellano y respecto al método anterior: “más dificil”). Se puede emplear el mismo 
procedimiento anterior con idénticos resultados. La única diferencia radica en definir el 
punto de corte antes de invocar a la función _vbaStrCmp para evitar sobrescribir al 
registro EAX que señala al número de serie correcto. 


d eax ->ADUJSDMD8 3870794 98SOPEMNSD 


Name/Serial 


Este ejemplo ya es algo más difícil. Nada se obtendrá aquí con la función 
_vbastrCmp, deberá considerarse otro punto de entrada distinto al programa. Se podrá 
definir el punto de corte a la bien conocida función rtcMsgBoX quien dará cuenta del 
número de serie introducido incorrectamente. Á continuación se podrá localizar desde 
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donde se invocó la función. También se puede establecer el punto de corte en la función 
API Hmemcpy. Ambos casos conducirán al mismo código: 


:0040F322 mov eax,0000000A 

:0040F327 mov ecx,80020004 

:0040F32C mov [ebp-64] ,eax 

:0040F32F mov [ebp-54] ,eax 

:0040F332 mov eax, [ebp-18] <-- d eax 

:0040F335 mov [ebp-5C],ecx 

:0040F338 mov [ebp-3C] ,eax 

:0040F33B mov [ebp-4C] ,ecx 

:0040F33E mov eax,00000008 

:0040F343 lea edx, [ebp-74] 

:0040F346 lea ecx, [ebp-34] 

:0040F349 mov [ebp-18],ebx 

:0040F34C mov [ebp-44] ,eax 

:0040F34F mov dword ptr [ebp-6C],0040BC44 

:0040F356 mov [ebp-74],eax 

:0040F359 call [MSVBVM60!  vbaVarDupl] 

:0040F35F lea eax, lebp-64] 

:0040F362 lea ecx, lebp-54] 

:0040F365 push eax 

:0040F366 lea edx, [ebp-44] 

:0040F369 push ecx 

:0040F36A push edx 

:0040F36B push 10 

:0040F36D jmp 0040F412 <--MessageBox - número de serie 
o nombre introducido incorrecto 


De introducirse el mandato d eax tras haber procesado la instrucción definida en 
la dirección 0040F332, se obtendrá algo muy semejante a lo siguiente en la ventana de 
datos: 


Algo más adelante se podrá observar el número de serie correcto. Para el nombre 
aquí empleado —ZemoZ, el número de serie correcto es 272820394—, 
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Matrix 


Todavía no se va a considerar este método de protección. Puesto que es ligeramente 
más complejo, se utilizará un ejemplo similar no codificado en Visual Basic para facilitar 
su comprensión. 


KeyFile 


En este apartado se ilustra de manera muy sencilla la protección basada en un 
fichero clave. 


Se aplica la función —vbafileopen para acceder al fichero en Visual Basic. Al 
definir el punto de corte a esta función y pulsar en el botón “KeyFile” del programa, 
SoftICE mostrará (F1 1) lo siguiente: 


:0040F506 push 0040BCCO <-- nombre del fichero wk.dat 
:0040F50B push 01 

:0040F50D push FF 

:0040F50F push 01 

:0040F511 call [MSVBVM60!  vbaFileOpen] 

:0040F517 mov ebx, [MSVBVM6 0 ! rtcEndof File] 


Tras introducir el mandato d 0040BCCO se observará que el fichero buscado se 
llama wk.dat. También se podrá observar el siguiente texto: 


w.k...d.a 
A E AN ES 
e.h.? 


El texto “Easy, eh?” constituye el contenido del fichero. Para entender mejor este 
mecanismo (aunque puede que esta vez no se haya contado con tanta fortuna), obsérvese a 
algo más abajo el código del programa, En un punto concreto se invoca a la función 
_vbaVatTstEq. Esta función compara el contenido del fichero con la secuencia de 
caracteres en la dirección OO4JOBCDA, esta secuencia es “Easy, eh?”. 


:0040F536 mov dword ptr [ebp-48] , 0040BCD4 gee 
dirección necesaria 

:0040F53D mov dword ptr [ebp-50] ,00008008 

:0040F544 lea eax, [esi+34] 

:0040F547 push eax 

:0040F548 lea ecx, [ebp-501 
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:0040F54B push ecx 
:0040F54C call [MSVBVM60!  vbaVarTstEq] 


:0040F552 test ax,ax <-- Comparación - si AX =0, 
los datos comparados no son 
idénticos 


:0040F555 mov edx, [esi] 

:0040F557 push esi 

:0040F558 jz 0040F583 <-- bifurcación = fichero 
clave incorrecto 


NAG 


Ya se eliminó una ventana de advertencia (en inglés, “NAG screen”) al comienzo, 
Aquí se suprimirá mediante el mismo procedimiento (bpx msvbwvm60 ! rtemsgbox). 


La ventana de advertencia se crea en la dirección siguiente: 


:00412B6A call [MSVBVM60!rtcMsgBox] 
:00412B70 lea ecx, [ebp-1C] 


Aplíquese la instrucción NOP como anteriormente y problema resuelto. 


Cripple 


Seguidamente se podrá observar lo fácil que resulta habilitar un elemento de control 
previamente inhabilitado. 


Arránquese el programa The Customiser (comentado anteriormente), púlsese el 
botón “Edit Window”, a continuación “Select” y luego el botón “On”. Elíjase un botón 
inhabilitado y púlsese. Selecciónese la opción “Enable window” de la pestaña “Misc.” y 
luego el botón “Do now”. ¿Verdad que es fácil? 


DUELIST - CRACKME +5 


El objetivo de este ejercicio consiste en suprimir la ventana de advertencia mostrada 
durante el arranque del programa y modificar la secuencia de caracteres “Unregistered” en 
“Registered”. Aunque parezca simple, el programa también está codificado con un 
codificador-compresor PE, lo que impide editarlo directamente mediante un editor 
hexadecimal. 
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Existen varias alternativas para solucionar el ejercicio. Se puede guardar el 
programa en formato descomprimido y luego editarlo tal cual, o bien aplicar las 
modificaciones directamente en memoria. Se mostrarán ambas opciones. 


Descodificación manual de un fichero 


En primer lugar, deberá conocerse cómo funciona el bucle de compresión y de 
descompresión, sobre todo dónde empieza, dónde finaliza y cómo descomprime los datos. 
Para ello cárguese el fichero en el cargador de símbolos, ignórense las advertencias y 
arránquese. SoftICE, listo para comenzar la depuración en la dirección del punto de 
entrada al programa, mostrará inmediatamente: 


:00406600 push ebx 

:00406601 push ecx 

:00406602 push edx 

:00406603 push esi 

:00406604 push edi 

:00406605 push ebp 

:00406606 call 0040660B <-- estas líneas 

:0040660B pop ebp <-- deberían atraer 

:0040660C sub ebp, 00403034 <-- la atención del 
lector 

:00406612 call [ebp+004034E8] <-- ¡¡anti-cargador!! 

:00406618 mov eax,00403029 

:0040661D add eax,ebp 

:0040661F sub eax, [ebp+0040340D] 

:00406625 mov [ebp+00403419] ,eax 

:0040662B cmp dword ptr [ebp+00403401],00 

:00406632 jnz 00406651 

:00406634 nop 

:00406635 nop 

:00406636 nop 

:00406637 nop 

:00406638 mov dword ptr [ebp+00403401] 00000001 


:00406642 call 00406665 <-- rutina de descompresión 
:00406647 call 00406871 <-- procesando reubicaciones 
:0040664C call 0040692B <-- ¡procesando importaciones 
:00406651 mov eax, [ebp+00403405] <-- cálculo de la 


RVA del punto de 
entrada original 
al programa 
:00406657 add eax, [ebp+00403419] <-- EAX = VA del 
punto de entrada 
al programa 
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:0040665D pop ebp 

:0040665E pop edi 

:0040665F pop esi 

:00406660 pop edx 

:00406661 pop ecx 

:00406662 pop ebx 

:00406663 jmp eax <-- bifurcación al punto de entrada 

original del programa 


Para quien haya leído el capítulo 7 sobre el formato PE, este código debe resultarle 
familiar. Se puede afirmar con seguridad que constituye un código de control de cierto 
compresor o codificador PE. La estructura es típica: una instrucción CALL-POP para 
calcular el desplazamiento de las variables, procesamiento de datos importantes, un par de 
instrucciones CALL para comprimir los datos y procesar las importaciones y 
reubicaciones, y por último, una bifurcación a los datos originales. 


La instrucción CALL en la dirección 00406612 resulta muy interesante, ya que si el 
programa se arrancara en Windows NT con el cargador de símbolos, provocaría un error 
en su ejecución. Esta instrucción no es más que una simple invocación a la función API 
GetProcAddress: no debe malgastarse el tiempo buscando algún tipo de algoritmo de 
protección en esta instrucción CALL. La causa del error radica en que el valor del registro 
EDI no es cero (como sería el caso en Windows 9x o como cuando no se utiliza un 
cargador de símbolos), sino 6BOOBGH. Si se deseara utilizar el cargador en Windows NT, 
deberá emplearse la instrucción NOP con CALL (el código de un compresor PE no utiliza 
ninguna comprobación de integridad) o bien saltársela cada vez mediante el mandato y 
eip address. 


Si se sigue estudiando el código, se observará que define un compresor PE, de fácil 
eliminación, diseñado para reducir el tamaño del fichero más que para protegerlo. Los 
datos se descomprimen con fiabilidad y se puede seguir fácilmente el proceso hasta la 
dirección 00406663 donde se produce una bifurcación a los datos originales. La 
bifurcación se realiza mediante la instrucción JMP EAX, lo que simplifica hallar el punto 
de entrada original al programa. EAX equivale a la dirección VA del punto de entrada 
original al programa, de valor 00401000, que significa un valor de 1000h (ImageBase = 
40000h) para la dirección de RVA. 


Ya se cuenta con todos los datos necesarios. Ahora se podrá modificar el programa 
de tal manera que se realice un volcado mediante ProcDump una vez haya quedado 
descomprimido. En primer lugar, no debe olvidarse borrar todos los puntos de corte 
definidos dentro del código del programa, en caso contrario las posiciones de los puntos de 
corte quedarían sobrescritas con el valor CCh en el volcado. Si se desea realizar el volcado 
del programa con éxito, no debe arrancarse el código descomprimido que se desea volcar. 
Por tanto, ejecútese el mandato siguiente en SoftICE: 
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a 00406663 

Y a continuación: 

jmp eip 

Pulsando “intro” se confirmará la escritura de los datos sobre los antiguos; el 
proceso concluirá al pulsar la misma tecla por segunda vez. Así, la instrucción JMP EAX 
se habrá transformado en JMP EIP, o para ser más exactos, JMP 00406663. Con ello se 


creará un bucle infinito dentro del programa que evitará arrancar el código descomprimido. 


Arránquese ahora ProcDmp, elíjase el proceso de programa y selecciónese la 
opción Dump (Full) pulsando el botón derecho del ratón. 


Pr ProcDump32 (C) 1998, 1999, 2000 G-RoM, Lorian 8: Stone: 


cuinntlamcapSa.exe p0000150 00400000 0022000 ODODO0DÓ 
csJwinntisystem321notepad.exe ONO0003BC 01000000 00010000 00000000 
cslprogram filestmicrosoft officefoffice,., 000002B0 30000000 DDASFOOO DOD00000 
c:winntisystem32|mdm.exe 000003FO 00400000 O0D1E000  DO00D000 
00000440 00400000 00019000 00000000 
ponsasTE 00400000 00006B10  DO000000 


ci documents and se 00400000 00006610 
c:jwinntisystem3Z|n — Process Infos 77F80000 00079000 
ci Ywinntisystem32Ya ==> B 7780000 ODOB6000 
cijwinntisystem32yu Refresh list 77€10000 00065000 
c:fwinntisystem321gdT3Z; 77F40000 — 0003CO00D 
ciwinntisystem321nvdesk32. dll 10001900 10000000 00019000 


cilwinntisvstem321comcti32.dll 77B5BEE4 77850000 D00BADOO 


Figura 9-10. El volcado constituye una herramienta verdaderamente poderosa 


Una vez que se haya guardado en disco los contenidos de la memoria (volcado), 
suprimase el proceso (nunca finalizará por sí mismo a causa del bucle infinito) mediante la 
opción “Kill task”, 


Si se intentara arrancar el fichero ahora, no se conseguiría. Deberá sobrescribirse el 
punto de entrada al programa con su valor original y cerciorarse de que se renueva la tabla 
de importaciones inicial con todas las funciones del programa (el compresor PE incluye su 
propia tabla importaciones y procesa el mismo la tabla original). ProcDump sirve bien para 
realizar esta tarea. En primer lugar, púlsese el botón “PE-Editor” y sobrescríbase el punto 
de entrada al programa con el valor correcto (sustitúyase el valor 6600h con 1000h). A 
continuación púlsese el botón “Options” y luego la opción “Rebuild import table” del 
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menú “Rebuilder Options — Imports”. Confírmese la selección (OK) y luego púlsese el 
botón “Rebuild PE”. 


Tras haber realizado los pasos anteriores correctamente, se obtendrá un fichero EXE 
descomprimido y plenamente operativo. Aunque así parezca demostrarse cómo se 
descomprime manualmente un programa protegido con un compresor PE, no siempre 
resulta tan sencillo. 


Toca ahora volver al objetivo inicial de este ejemplo: suprimir la ventana de 
advertencia inicial y cambiar el mensaje “Unregistered” por “Registered”. Al disponer de 
un programa de descompresión, esta tarea apenas requiere esfuerzo. Inicialmente se 
suprimirá la ventana de advertencia. 


Unregistered 


Please obtain a valid license code at duelistodbeer, com! 


Figura 9-11. Otra “útil” ventana de advertencia 


Definase el punto de corte a la función API MessageBoxa: 
bpx MessageBoxA 


Afortunadamente el programa utiliza esta función. Se observará el código siguiente 
en SoftICE: 


0040105C jmp 004010C1 


004010C1 push 00002000 

004010C6 push 0040205C 

004010CB push 00402017 

004010D0 push 00 

004010D2 call USER32!MessageBoxA <-- aquí 
004010D7 push 00 


Podría bastar con aplicar la instrucción NOP a la invocación de la función; sin 
embargo, ello obligaría a modificar el valor de la pila (cuatro instrucciones PUSH antes de 
la función —la función contiene cuatro parámetros—). Una solución más refinada 
consistiría en utilizar la anterior instrucción JMP 004010C1. El ejercicio quedaría resuelto 
y la ventana de advertencia suprimida si se modificara esta instrucción para que se 
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bifurcase tras la instrucción de la dirección 004010D2 donde se invoca la función APL, 
esto es, dirección 004010D7. 


El segundo objetivo consiste en modificar el mensaje informativo sobre el estado 
del programa. 


Duelist's Crackme +5 


Program Status: 


| Unregistered 


Figura 9-12. Programa no registrado (por poco tiempo) 


Buscando en la lista de funciones importadas, se puede encontrar un buen 
candidato: la función API SendDlgItemMessagea. Al establecer el punto de corte en 
esta función, se obtendrá el código siguiente: 


00401130 push 0040205€  <-- señala la secuencia de 
caracteres wUnregistered” 

00401135 push 00 

00401137 push 0C 

00401139 push 03 

0040113B push dword ptr [ebp+08] 

0040113E call USER32 ! SendD1gItenMessageA ga 


invocación de la función 


La instrucción PUSH 0040205C en la dirección 00401130 determina el parámetro 
de la función SendD1gItemMessageA, concretamente el texto que debe mostrarse. En 
la dirección 0040205C se puede encontrar esta secuencia de caracteres, esto €s, 
“Unregistered”. Con objeto de hacer el ejercicio más fácil, el autor ubicó 
intencionadamente la segunda secuencia, “Registered”, justo encima, en la dirección 
00402050. El siguiente paso resulta obvio. Transfórmese la instrucción PUSH 0040205C 
en PUSH 00402050 y así quedará modificada la secuencia de caracteres. Fin de este 
ejercicio. 


Modificaciones efectuadas directamente en memoria 


Si se añade el código oportuno en el programa, se pueden efectuar modificaciones 
directamente en memoria. Debido a la compresión que aquí se utiliza, resulta necesario 
insertar el código en algún sitio que no vaya a descomprimirse. En este caso se ha elegido 


la ubicación de memoria que comienza en la dirección 0040583F. 
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Lógicamente, el código que modifica la memoria debe arrancarse tras la 
descompresión del programa. Por tanto, se utilizará la instrucción JMP EAX, empleada 
para bifurcar al punto de entrada original del programa, sobrescribiéndola con una 
bifurcación a la dirección necesaria, esto es, 0040583F. La instrucción JMP 0040583F 
tiene cinco bytes de longitud (a diferencia de la instrucción JMP EAX, que tiene dos), lo 
que lleva también a sobrescribir las últimas tres instrucciones POP (cada una ocupa un 
byte). Así que el código en la dirección 0040583F tendrá que efectuar las modificaciones y 
contener las instrucciones POP sobrescritas además de IMP EAX. 


A continuación se indica el código completo: 


0040583F:5A pop edx 

00405840:59 pop ecx 

00405841:5B pop ebx 
00405842:C7055C104000EB796A00 mov dword ptr 


[0040105C] ,006A79EB <-=- ventana de advertencia 
0040584C:C7053011400068502040 mov dword ptr 
[00401130] ,40205068 <-- “Registered” 


00405856:FFEO jmp eax 


TC - CRACKME 9 <ID: 6> 


Este programa aplica un método protección estándar con el que se genera el número 
de serie que debe introducirse a partir de un nombre y de una organización. 


a CrackMe [id:6] 
Exit About Register 


| ; 


User Name 


Organisation 


WI 


Seal Number 


Figura 9-13. Campos por rellenar 


Obtención manual del número de serie 


Introdúzcase cualquier valor (con al menos cinco caracteres) y selecciónese el ítem 
“Verify entries” del menú “Register”. Aparecerá un diálogo con el texto “Invalid serial”: 
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exactamente todo lo que se necesita para proseguir. Desensámblase el programa y 
búsquese la secuencia “Invalid serial” en la lista de referencias. Operación que conducirá 
al código siguiente: 


*+Possible StringData Ref from Code Obj ->"Invalid 
Serial !!!” 


:00442B33 B8542B4400 mov eax,00442B54 

:00442B38 E85BF9FFFF call 00442498 

:00442B3D 33C0 xor eax, eax 

:00442B3F A338584400 mov dword ptr [00445838], eax 
:00442B44 C3 ret 


Esta parte del código del programa muestra un cuadro de diálogo informando acerca 
del número de serie incorrecto. 


Anteriormente se puede observar lo siguiente: 


*Referenced by a CALL at Address: 
:00442B80 


*+Referenced by a (U)nconditional or (C)onditional Jump 
at Address: 
:00442A75(C) 


:00442AE0 6A00 push 00000000 


*+Referenced by a (U)nconditional or (C)onditional Jump 
at Address: 
:00442A77 (C) 


:00442AE2 668B0D002B4400 mov cx,word ptr [00442B00] 
:00442AE9 B203 mov dl, 03 


*Possible StringData Ref from Code Obj - 
>"Congratulations - you did it!!” 
:00442AEB B80C2B4400 mov eax,00442B0C 


*+Referenced by a (U)nconditional or (C)onditional Jump 
at Address: 
:00442A7E (C) 
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:00442AF0 EBA3F9FFFF call 00442498 

:00442AF5 C7053858440001000000 mov dword ptr 
[00445838] ,00000001 

:00442AFF C3 ret 


Esta función muestra un cuadro de diálogo notificando al usuario que ha 
introducido con éxito un nombre, el nombre de una organización y el número de serie. Si 
se observa con detenimiento, se podrá observar que se invoca mediante una instrucción 
CALL en la dirección 0442B80: 


*Referenced by a CALL at Address: 
:00442B80 


Esta dirección resulta muy interesante, quizás el número introducido y el número de 
serie correcto se comparen en algún punto próximo a esta dirección y el código del 
programa sea entonces el que decida qué mensaje debe mostrarse. Obsérvese la parte del 
código que contiene esta instrucción CALL: 


*Referenced by a CALL at Address: 
:00442DE3 


:00442B68 A144594400 mov eax,dword ptr [00445944] Has 
<-- número de serie correcto 
:00442B6D 8B1534584400 mov edx,dword ptr [00445834] 
<-- número de serie introducido 
:00442B73 E8CCOFFCFF call 00403B44 <-- Comparación 
:00442B78 7406 je 00442B80 <-- bifurcación = número 
<-- de serie introducido correcto 
:00442B7A EBA9FFFFFF call 00442B28 <-- “Invalid 
Serial” 
:00442B7F C3 ret 


*Referenced by a (U)nconditional or (C)onditional Jump 
at Address: 
:00442B78 (C) 


:00442B80 E85BFFFFFF call 00442AE0 <-- nuestra CALL 
<-- “Congratulations - you did it!!” 
:00442B85 C3 ret 


Justo por encima de la instrucción CALL buscada, se puede hallar el código del 
programa que decide cuándo invocar esta instrucción. Compara el número de serie 
introducido con el correcto, cuando estos dos valores sean idénticos, invocará una CALL 
en la dirección 00442B80 para mostrar el texto “Congratulations — you did it!!”. Si los 
números resultarán diferentes, se mostrará un cuadro de diálogo con el texto “Invalid 
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Serial”. La estructura de todo el algoritmo de comparación resulta bastante típica y casi 
imposible de ignorar. 


Decidase el punto de corte a la instrucción MOV (en la dirección 00442B6D), que 
almacena el puntero al número de serie correcto en el registro EAX. Para mostrar el 
número de serie correcto en la ventana de datos bastará con introducir un mandato que 
muestre los contenidos de la memoria donde señala EAX: 


d eax 

Con la siguiente información de registro: 
Name: ZemoZ 

Organization: ZemoZ s.r.0. 


Se obtiene el siguiente número de serie correcto: 3168-159357-41184-1D-313. 


Conversión del programa en un generador de claves 


Otro método muy elegante de encontrar el número de serie correcto conforme a la 
combinación introducida de nombre y organización, consiste en modificar el programa de 
tal manera que muestre el número de serie él mismo. En otras palabras: se utiliza el propio 
programa para construir un generador de claves, esto es, un generador de números de serie 
correctos. 


Considérese en primer lugar la parte del código donde se genera el número de serie 
correcto para luego decidir cómo alterar el programa: 


*+Referenced by a CALL at Address: 
:00442DE3 


:00442B68 A144594400 mov eax,dword ptr [00445944] <-- 

EAX = puntero al número de serie correcto 
:00442B6D 8B1534584400 mov edx,dword ptr [00445834] 
:00442B73 E8CCOFFCFF call 00403B44 <-- comparación 
:00442B78 7406 je 00442B80 <-- bifurcación = número 

de serie correcto introducido 
:00442B7A EBA9FFEFFF call 00442B28 <-- “Invalid 
Serial” 

:00442B7F C3 ret 


+Referenced by a (U)jnconditional or (C)onditional Jump 
at Address: 
:00442B78 (C) 
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:00442B80 E85BFFFFFF call 00442AE0 <-- “Congratulations 
- you did it!!” 
:00442B85 C3 ret 


Tras examinar este código, se puede llegar fácilmente a la conclusión de que la 
manera más sencilla de mostrar el contenido del registro EAX, es decir, el número de serie 
correcto, consista en emplear el cuadro de diálogo donde se notifica al usuario acerca del 
número de serie (correcto o no). En este caso se utiliza el cuadro de diálogo “Invalid 
Serial”, Obsérvese cómo se lee el texto pertinente en el cuadro de diálogo. 


:00442B2A 668B0D482B4400 mov cx,word ptr [00442B48] 
:00442B31 B201 mov dl, 01 


*Possible StringData Ref from Code Obj ->"Invalid Serial 
pryo 


:00442B33 B8542B4400 mov eax,00442B54 <-- aquí 
:00442B38 EB85BF9FFFF call 00442498 

:00442B3D 33C0 xor eax,eax 

:00442B3F A338584400 mov dword ptr [00445838] ,eax 
:00442B44 C3 ret 


Cuando se introduzca un mandato que muestre el contenido de la memoria donde 
señala el registro EAX tras haberse procesado la instrucción MOV, se podrá observar el 
código siguiente: 


00442B54:49 6E 76 61 6C 69 64 20 — 53 65 72 69 61 6C 20 21 
Invalid Serial !! 
00442B64:21 21 00 11 


De hecho éste es el texto del cuadro de diálogo. Queda claro, por tanto, que el 
registro EAX debe señalar el texto del cuadro de diálogo antes de que se invoque la 
instrucción CALL 0442498 en la dirección 00442B38 encargada de mostrar el cuadro de 
diálogo. Afortunadamente dicho puntero al número de serie correcto también se almacena 
en el registro EAX con dirección 00442B68. Procede, por tanto, utilizar tal valor. 


Desgraciadamente la instrucción CALL en la dirección 00442B73, que compara el 
número de serie introducido con el correcto, modifica el contenido del registro EAX; 
resulta necesario, por tanto, saltarse dicha instrucción. Lo mismo se puede decir de la 
instrucción JE siguiente, donde se decide mostrar uno de los cuadros de diálogo según el 
valor del indicador definido por CALL. Así siempre se mostrará el cuadro de diálogo 
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recién modificado (para ello resulta necesario introducir al menos un número en el campo 
“Serial number”). 


Ya se ha conseguido que el puntero al número de serie correcto resida en el registro 
FAX antes incluso que en la instrucción CALL de la dirección 00442B7A. Resta tan sólo 
saltarse la instrucción MOV en la dirección 00442B33, que guarda el puntero al texto 
original del cuadro de diálogo en el registro EAX. 


Basta sencillamente en este caso con aplicar la instrucción NOP a todas las 
instrucciones “redundantes” para que el programa se transforme en un generador de 
números correctos. Ahora, en vez del texto “Invalid Serial”, se mostrará el número de 
serie apropiado según la combinación introducida de nombre y organización. 


cu Cracks 10 x] 


Exit —ábout Recister 


[Zemaz 


User Name z > 


[Zemaz 5.1.0 


Figura 9-14. El programa ya muestra el número de serie correcto 


TC - CRACKME 10 <ID: 7> 


e CrackMe [id:?] 
Menue a 
[This is a time-limited demo version of 
-CrackMe [id:7]-. You can order the full 


version for 450% (pupils and students must 
only pay the half]. 


This demo version will only work for 20 
seconds, then lt will shut-down and pou had 
to restart it. So ¡ts better to pay for itl 


Figura 9-15, Cuenta atrás de la duración limitada 
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Este sencillísimo ejemplo utiliza una protección basada en la duración limitada del 
programa. Expira transcurridos 20 segundos. 


En primer lugar, debe considerarse un punto de entrada apropiado al programa. 
Resulta muy probable que con objeto de contar 20 segundos, el programa utilice un 
contador y la función API SetTimer, Desgraciadamente, no es ésta precisamente la 
mejor manera de definir un punto de corte dado el gran número de programas, incluyendo 
procesos del sistema, que utilizan esta función (la mayor parte del tiempo). 


Por tanto, arránquese el desensamblador y obsérvese la lista de funciones 
importadas. Se apreciará que el programa llama realmente en tres ocasiones a la función 
API SetTimer. Tras examinar brevemente el programa se encontrará que el límite 
temporal buscado se ubica en la tercera llamada a esta función. El código es el siguiente: 


:0043D3DF cmp word ptr [ebx+2E],00 

:0043D3E4 jz 0043D419 <-- bifurcación = que no se 
establezca contador 

:0043D3E6 push 00 

:0043D3E8 push esi <-- tiempo - 21 segundos 

:0043D3E9 push 01 

:0043D3EB mov eax, [ebx+28] 


:0043D3EE push eax <-- manejador de la ventana 

:0043D3EF call USER32!SetTimer 

:0043D3F4 test eax,eax <-- ¿tiempo definido 
correctamente? 


:0043D3F6 jnz 0043D419 <-- bifurcación = sí 
:0043D419 xor eax, eax 


Existen más alternativas para modificar el programa con objeto de que no incluya 
una duración limitada. Probablemente sea la mejor solución saltarse por completo la 
función SetTimer para que no se defina ningún contador. Para ello, basta en este caso 
con modificar la instrucción JZ 0043D419 en la dirección 0043D3E4 a una instrucción 
JMP para que la duración limitada se suprima. 


TC - CRACKME 13 <ID: 10> 


Nada más comenzar este ejemplo se observará que el ítem del menú denominado 
“Menue” está inhabilitado. Se pretende ahora habilitarlo. 
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Exit About - 


Menue 


hunclors 


Figura 9-16. tiem deshabilitado inutilizable aparentemente 


Como de costumbre, el primer paso siempre ha de consistir en encontrar el mejor 
punto de entrada al programa, que conducirá lo más cerca posible del algoritmo de 
protección. Resulta por tanto necesario considerar la función que el programa pudiera 
utilizar para inhabilitar un botón del menú. Los nombres de las funciones API 
normalmente se derivan de su objetivo: probablemente la función buscada contenga la 
palabra “menu” en su nombre. Tras examinar la tabla importaciones, se destacan algunas 
posibles funciones API candidatas: 


EnableMenultem 
InsertMenulItemA 
SetMenuTtemInfoA 


La más obvia parece ser la función EnableMenultem. Sin embargo, si se 
definiera el punto de corte a esta función, el lector se perdería entre las llamadas a las 
diversas librerías puesto que el programa no emplea esta función con ese objetivo. 
Desgraciadamente, tampoco sirve de mucho la función SetMenuTtema, Así que sólo 
queda la función API InsertMenuTtema, empleada para añadir un ítem nuevo al menú. 
Lo cual lleva a pensar que el botón se creó deshabilitado inicialmente y no a posteriori. 
Defínase el punto de corte a la función API InsertMenultemA y arránquese el 
programa. SoftICE aparecerá en pantalla mostrando el código siguiente tras haber pulsado 
el botón Fl 1: 


:00431B30 lea eax, [ebp-39] 

:00431B33 push eax <-- estructura MENUITEMINFO 
:00431B34 push FP 

:00431B36 push FF 

:00431B38 push edi 

:00431B39 call USER32! InsertMenulItemA 

:00431B3E jmp 00431BCA 

:00431B43 mov eax, [ebx+24] 

:00431B46 mov edx, 00431C0C 
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Esta rutina se invoca cuando todos los ítems del menú están cargados. No es nada 
espectacular pero permite conocer los parámetros de esta función: 


BOOL WINAPI InsertMenultem( 
HMENU hMenu, 
UINT ultem, 
BOOL fByPosition, 
LPMENUITEMINFO 1pmii 
); 


Concretamente, es el último parámetro el que se está buscando, un puntero a la 
estructura MENUITEMINFO. Esta estructura contiene información sobre un ítem del 
menú específico. Se muestra a continuación su contenido: 


typedef struct tagMENUITEMINFO ( 
UINT cbSize; 
UINT fMask; 
UINT fType; 
UINT fState; <-- objeto de la búsqueda 
UINT wID; 
HMENU hSubMenu; 
HBITMAP hbmpChecked; 
HBITMAP hbmpUnchecked; 
DWORD dwItemData; 
LPTSTR dwTypeData; 
UINT cch; 
)MENUITEMINFO, FAR *LPMENUITEMINFO; 


La variable señalada fState define el estado del ítem: habilitado 
(MFS_ENABLED), inhabilitado (MFS_DISABLED), destacado (MFS_HILITE), etc. 


Excepto en una ocasión, todas las llamadas a la función API 
InsertMenuTtemA del programa se realizan con el valor de la variable fState 
igual a cero, MFS ENABLED. La única excepción es la que crea el botón "Menue" 
inhabilitado. En este caso, el valor de la variable equivale a tres (MFS GRAYED = 
MFS_ DISABLED). 


Probablemente ya se haya adivinado el propósito de este procedimiento. Bastará 
con sobrescribir la variable £State del botón inhabilitado con el valor cero para 
habilitar el botón "Menue" creado. 
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El siguiente paso consiste en borrar todos los puntos de corte (bc *) y definir 
uno nuevo a la dirección 00431B33 (parámetro necesario de la función). Compruébese 
el contenido de la estructura MENUITEMINEO con cada interrupción realizada en la 
ejecución del programa y obsérvese el valor de la variable £State cuando sea igual 
a tres. Al guardarse el puntero a la estructura MENUITEMINFO en la dirección 
00431B30 del registro EAX, será preciso emplear el mandato siguiente: 


d eax 


Aparecerá lo siguiente: 


:0012FA93 2C 00 00 00 - 3F 00 00 00 - 00 00 00 00 - 00 00 00 00 
%*% - se está 
buscando 
esto; 
fState = 
MFS_ENABLED = 
(o) 

:0012FAA3 01 00 00 00 - 00 00 00 00 - 00 00 00 00 — 00 00 00 00 


Tras localizar la estructura MENUITEMINFO del botón inhabilitado, se observará 
algo parecido a lo siguiente en la ventana de datos: 


:0012FD43 2C 00 00 00 - 3F 00 00 00 - 00 00 00 00 - 03 00 00 00 
ne fState 


MFS_DISABLED 
= 3 dirección 
2 = 0012FD4F 
:0012FD53 03 00 00 00 - 11 01 06 00 - 00 00 00 00 - 00 00 00 00 


Con objeto de cambiar el valor £State de memoria, introdúzcase el mandato 
siguiente: 


eb address -—en este caso, eb 0012FD4F. 
Sustitúyase el valor de tres por cero (MFS_ ENABLED) y púlsese “intro”. 
El botón “Menue” quedará ahora plenamente operativo. Si se deseara guardar las 


modificaciones en el programa de forma permanente, los ejemplos anteriores enseñarán 
cómo hacerlo. 
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TC - CRACKME 20 <ID: 17> 


na CrackMe [id:17] by tE... 


Figura 9-17. Campos para realizar el registro 


Este programa emplea varios campos binarios (en inglés, “checkboxes”) para 
indicar la combinación de registro correcta. 


En primer lugar, debe intentarse desensamblar el programa para encontrar un punto 
de entrada apropiado. Obviamente, el programa no tendrá ningún mensaje codificado, así 
que deberá buscarse alguna secuencia de caracteres “sospechosa”. Tras inspeccionar el 
tiempo suficiente se observará que la secuencia de caracteres “Registered” puede constituir 
un buen punto de entrada para estudiar el código. Cuando se accede a ella, se observa que 
esta secuencia se ubica al final de algún algoritmo de comprobación. Este algoritmo 
comienza en la dirección 004402EC. Defínase pues un punto de corte a esta dirección, 
compruébese alguno de los campos binarios de programa y púlsese el botón <-check->. 
SoftICE mostrará el código siguiente: 


:004402EC push ebx 

:004402ED mov ebx,eax 

:004402EF mov eax, lebx+00000308] <-=- 2. 
:004402F5 mov edx, [eax] 

:004402F7 call [edx+000000B8] 

:004402FD test al,al 

:004402FF jnz 004403EB 

:00440305 mov eax, [ebx+00000310] <-- 4. 
:0044030B mov edx, [eax] 

:0044030D call [edx+000000B8] 

:00440313 test al,al 

:00440315 jnz 004403EB 

:0044031B mov eax, [ebx+0000031C] zo 
:00440321 mov edx, [eax] 

:00440323 call [edx+000000B8] 

:00440329 test al,al 

:0044032B jnz 004403EB 
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:00440331 mov eax, ebx+00000320] 
:00440337 mov edx, [eax] 
:00440339 call [edx+000000B8] 
:0044033F test al,al 
:00440341 jnz 004403EB 

:00440347 mov eax, ebx+00000324] g=- Y. 
:0044034D mov edx, leax] 

:0044034F call [edx+000000B8] 

:00440355 test al,al 
:00440357 jnz 004403EB 

:0044035D mov eax, ebx+00000328] <-- 10. 
:00440363 mov edx, [eax] 

:00440365 call [edx+000000B8] 

:0044036B test al,al 
:0044036D jnz 004403EB 

-0044036F mov eax, [ebx+00000330] <-- 12. 
:00440375 mov edx, [eax] 

:00440377 call [edx+000000B8] 

:0044037D test al,al 
:0044037F jnz 004403EB 

:00440381 mov eax, ebx+00000304] <--= 1. 
:00440387 mov edx, [eax] 

:00440389 call [edx+000000B8] 

:0044038F test al,al 
:00440391 jz 004403EB 

:00440393 mov eax, ebx+0000030C] == 3. 
:00440399 mov edx, [eax] 

:0044039B call [edx+000000B8] 

:004403A1 test al,al 
:004403A3 jz 004403EB 

:004403A5 mov eax, ebx+00000314] <=- De 
:004403AB mov edx, leax] 

:004403AD call [edx+000000B8] 

:004403B3 test al,al 

:004403B5 jz 004403EB 

:004403B7 mov eax, ebx+00000318] <--= 6. 
:004403BD mov edx, [eax] 

:004403BF call [edx+000000B8] 

:004403C5 test al,al 
:004403C7 jz 004403EB 

:004403C9 mov eax, ebx+0000032C] <-- 11. 
:004403CF mov edx, [eax] 

:004403D1 call [edx+000000B8] 

:004403D7 test al,al 

:004403D9 3jz 004403EB 

:004403DB mov edx,004403F8 

:004403E0 mov eax, [ebx+000002D0] 
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:004403E6 call 004210B0 
:004403EB pop ebx 
:004403EC ret 


La estructura de este algoritmo resulta muy sencilla. Consiste en doce partes 
idénticas, cada una de las cuales controla el estado de un campo binario. 


:00440XXX mov eax, [ebx+00000XXX] 
:00440XXX mov edx, [eax] 
:00440XXX call [edx+000000B8] 
:00440XXX test al,al 

:00440XXX jnz/jz 004403EB 


Los tres dígitos añadidos al registro EBX en la primera instrucción MOV de cada 
parte determinan a qué campo concreto se aplica el algoritmo. El primer campo viene 
identificado por el número menor —304h—, y el último, por el número mayor —330h—. 
Los campos se numeran en orden, de uno en uno. Sin embargo, su estado no se examina 
por orden, por lo que se indica mediante comentarios los números de serie 
correspondientes a cada campo durante la comprobación. 


Según se puede observar, las siete primeras partes del algoritmo contienen la 
instrucción JNZ al final, y las cinco siguientes, la instrucción JZ también al final. Estas 
instrucciones siempre se refieren a la misma dirección —-004403EB—, ubicación del 
mensaje de error “Unregistered”. Resulta siempre conveniente, por tanto, evitar una 
bifurcación. La instrucción CALL [EDX+B8h] siempre devuelve el estado de un campo 
binario específico (0 — no definido, 1 — definido), la siguiente instrucción TEST decide 
cuándo proceder con la bifurcación. Al tomar control de este procedimiento, se podrán 
observar cuáles son los campos binarios que deben comprobarse. Los campos examinados 
en las siete primeras partes, esto es, 2, 4, 7, 8, 9, 10, 12 serán los que no deban 
comprobarse, y los examinados en las cinco siguientes, es decir, 1, 3, 5, 6, 11, sí. Éste sería 
el resultado: 


(1,0,1,0) 
(1, 1,0:,07 


(0, 0,1,:0) 


Todo el ejemplo se divide en dos grupos de campos: uno a la derecha y otro a la 
izquierda. No es posible escribir directamente en el grupo de la derecha, para ello debe 
emplearse el grupo de campos de la izquierda. Aunque se intente, no se podrán introducir 
los valores del grupo izquierdo. No queda más remedio que introducir en el grupo de 
campos de la derecha los valores obtenidos a partir del grupo de la izquierda. 


GRA-MA 
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Afortunadamente no hay tantas combinaciones, 
determinar cómo debería ser el grupo 


posibles combinaciones: 
(0,1,0,0) 
(o,0,0,1) 
(o,0,0,1) 
(0,0,0,0) 
(0,0,1,1) 
[0,0,0 


) 
) 
) 
) 


(0,0,1,0 
(0,0, 1,1 
(0, 0,0, 1 


así que no resulta tan difícil 
de campos de la izquierda. Estas son algunas de las 
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Zemoz's Matti 


a . —Notregístered! — o 


Figura 9-18. Más campos de comprobación binarios 


Con este ejemplo se ilustra el uso 
indicar el registro. El principio 
contraseña o número de serie, 


empleados. 


de un grupo de campos de comprobación para 
subyacente resulta idéntico al basado en introducir una 
la única diferencia radica en los elementos de control 


Al no estar codificado este programa, resultará sencillo su desensamblaje. Sólo se 


observarán dos elementos en la referencia 


de secuencias de caracteres: “Not registered” y 


“Registration successful”. Estas secuencias conducirán directamente al sitio oportuno: 


:004013C5 mov 
:004013C9 xor 
:004013CB mov 
:004013D1 mov 


esi, lesp+10] 
edi,edi 

eax, [esi+00403 074] 
ecx, ebx 
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:004013D3 
:004013D4 
:004013D9 
:004013DC 
:004013DE 
:004013E0 
:004013E5 
:004013E6 


:004013E8 


:004013EE 


:004013F0 
:004013F1 
:004013F4 


:004013F7 


:004013F9 
:004013FD 


:00401 


400 


:00401403 


:00401 


:0040 


407 


409 


:0040140E 


:0040 
:0040 
:0040 


410 
415 
418 


:0040141D 


:00401 
:0040 


41F 
421 


:00401426 
:00401427 
:00401428 


:00401 
:0040 
:0040 


429 
42A 
42B 


push eax 

call 00401648 

mov ecx, leax+20] 

push 00 

push 00 

push 000000FO 

push ecx 

Call ebp <-- si se ha marcado el campo 

concreto, EAX = 1, en caso 
contrario, EAX = 0 
cmp eax, [esi+00403020] <-- Objetivo de la 
búsqueda 
jnz 00401410 <-- bifurcación = “Not 
Registered” 

inc edi 

add esi,04 

cmp edi,07 <-- ¿procesados íntegramente 
los siete campos de la fila? 

jl 004013CB <-- bifurcación = procesando 
el campo siguiente 

mov eax, [esp+10] 


add eax,1C <-- tras cada fila procesada - 
EAX = EAX +1Ch 

cmp eax,54 <-- ¿procesadas las tres filas? 
<= ¿FLO <= 54H 


mov [esp+10],eax 

jl 00401305 <-- bifurcación = procesando 
la fila siguiente 

push 004030D8 

jmp 00401415 <-- "Registration successful” 

push 004030C8 

lea ecx, [ebx+60] 

call 00401612 

push 00 

mov ecx,ebx 

call 00401642 

pop edi 

pop esi 

pop ebp 

pop ebx 

pop ecx 

ret 


La parte principal del algoritmo de comparación consiste en dos instrucciones CMP 
en las direcciones 004013F4 y 00401400 (dos bucles). La primera instrucción comprueba 
que los siete campos de cada fila se hayan procesado y la segunda, que se hayan procesado 
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todas las filas. Esta operación se puede definir en C++ mediante dos bucles “for” como los 
siguientes: 


for (line = 0; line < 3; line ++) 


( 
for (check_box = 0; check_box < 7; 
check_box++) 
( 
) 
) 


Ya se conoce cómo comprueba el algoritmo la validez de la combinación de los 
campos binarios marcados: uno tras otro, gradualmente y de fila en fila. 


Obsérvese la dirección 004013E8. Aquí se halla la instrucción CMP, encargada de 
comparar el valor del estado actual de un campo con el valor de la dirección 
ESI+00403020. Con cada iteracción, en otras palabras, con cada nuevo campo procesado, 
aumenta el valor del registro ESI (de cero) en cuatro (004013F1 ADD ESI, 4). Si los 
valores no resultaran idénticos, el flujo terminaría en el mensaje “Not Registered”. Ello 
indicará que la matriz con la que se comprueba la idoneidad de los campos marcados debe 
guardarse en la dirección 00403020 y los ítems individuales de esta matriz, a cuatro bytes 
de distancia. Ejecútese el mandato siguiente si se desea mostrar esta dirección en la 
ventana de datos: 


d 00403020 


Se observará algo semejante a lo siguiente: 


.00403020:01 00 00 00-00 00 00 00-01 00 00 00-01 00 00 00 
.00403030:01 00 00 00-00 00 00 00-01 00 00 00-01 00 00 00 
.00403040:01 00 00 00-00 00 00 00-01 00 00 00-00 00 00 00 
.00403050:01 00 00 00-01 00 00 00-01 00 00 00-00 00 00 00 
.00403060:01 00 00 00-01 00 00 00-01 00 00 00-00 00 00 00 


La función en la dirección 004013E6 obtiene uno si el campo está marcado y cero 
en caso contrario. La bifurcación a la dirección 004013EE exige que sean idénticos los 
valores obtenidos por esta función y los guardados en la dirección original 00403020. Con 
esta información se puede deducir lógicamente que el valor uno de la matriz adjunta 
significa marcado y cero significa que no se ha marcado el campo. 


Se sabe que los campos se comprueban uno a uno, fila tras fila, y que los ítems 
individuales de la matriz están a cuatro bytes de distancia. En otras palabras: 
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[ESIH+-00403020]; ESIZ0 — primer campo 
[ESI-+00403020]; ESIH4 — segundo campo 
[ESI+00403020]; ESIFS8 — tercer campo 


[ESI+00403020]; ESI=12 — cuarto campo 


Tras haber escrito todos los valores, el resultado será: 


Seguidamente se muestra el código de este ejemplo el lenguaje C++: 


[*****x** campo con el que se determina la combinación 
correcta de los campos binarios - sólo realizable con 
un ejemplo de práctica del cracking*******/ 

int registration [3] [7] == 


/*** campo con los identificadores de los campos 
binarios***/ 
int items [3] [7] == 
( 
(IDC ROCO, IDC _ROC1,IDC ROC2,IDC_ROC3,IDC_ROC4,IDC_ROC5, 
IDC_ROC6), 
(IDC R1C0,IDC R1C1,IDC R1C2,IDC R1C3,IDC_R1C4,IDC_R1C5, 
IDC_R1C6), 
(IDC R2C0, IDC R2C1, TDC _R2C2., IDC R203,TDC_R2C4, IDC R2C5, 
IDC R2C6), 
hi 
void CCrackMe3D1g::0n0K() 
( . 
int 1,3]; 
BOOL Flag = FALSE; 
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for (i =0;1 <3;1++) // procesando filas 


( 


for (] =0;3 <7;]++) // procesando columnas 


if (((CButton*)GetDlgltem(items [il [31))- 
>GetCheck ()== registration [il[j1) // comparando 
// el estado 
// actual de 
// los campos 
// con la 
// combinación correcta 


( 


Flag =TRUE; 
continue; 
else 
[ 
Flag =FALSE; 
break; 
) 
if (!Flag) 
break; 
if (Flag) 
m_reg ="Registration successful!"”; 
else 


m_reg ="Not registered!"; 


UpdateData (FALSE) ; 


ZEMOZ -—- CRCME 


El objetivo de este programa consiste en suprimir la ventana de advertencia que 
aparece cada vez que se arranca. 


This NAG screen will bother you every time you start this program 


Figura 9-19, Éste es el objetivo que se persigue 
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Aquí a la situación se vuelve algo más complicado a causa de la comprobación de 
integridad aplicada a los datos, que debe suprimirse antes de que el programa constate que 
se ha modificado su código. 


ER Program A a 
| 


| The program code has not been modified 


Figura 9-20. Código del programa sin modificar (por ahora) 


Como primer paso debe conocerse desde dónde y cómo se invoca y crea la ventana 
de advertencia. Puede probarse con la función API MessageBoxaA. Defínase el punto de 
corte a esta función mediante el mandato bpx MessageBoxaA y arránquese el programa. 
Esta vez no aparecerá SoftICE, lo que indica que el programa probablemente no esté 
empleando esta función para crear la ventana de advertencia (que el lector puede dar por 
hecho y ahorrarse el tiempo de comprobarlo). Tampoco se obtendrán mejores resultados 
con otras funciones API conocidas, lo que exige considerar otras opciones distintas para 
detectar la creación de la ventana de advertencia. Tal vez se genere mediante un cuadro de 
diálogo nuevo. 


Arránquese W32Dasm y púlsese la referencia de diálogos. Se observará lo siguiente: 


Dialog:DialogID_0066 
Dialog:DialogID_0067 


El primer cuadro de diálogo con el identificador 66 constituye el cuadro de diálogo 
principal del programa, el segundo cuadro de diálogo es la ventana de advertencia buscada. 
Debe ahora encontrarse dónde se crea y desde dónde se invoca. Al pulsar en el segundo 
cuadro de diálogo correspondiente a la ventana de advertencia se obtendrá la parte del 
código siguiente: 


* Referenced by a CALL at Address; 
| :00401661 


:00401A00 8B442404 mov eax, dword ptr [esp+04] 
:00401A04 56 push esi 

:00401A05 50 push eax 

:00401A06 8BF1 mov esi, ecx 
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* Possible Reference to Dialog: DialogID_0067 
:00401A08 6A67 push 00000067 


* Reference To: MFC42 .Ordinal :0144, Ord: 0144h 


:00401A0A E803020000 Call 00401C12 

:00401A0F (070600244000 mov dword ptr [esi], 00402400 
:00401A15 8BC6 mov eax, esi 

:00401A17 5E pop esi 

:00401A18 C20400 ret 0004 


Es aquí donde se inicia y muestra el cuadro de diálogo. Puesto que la función se 
invoca desde la dirección 00401661, ahí deberá acudirse para decidir el paso siguiente: 


00401659 6A00 push 00000000 
:0040165B 8D8D44FFFFFF lea ecx, dword ptr [ebp+FFFFFF44] 
:00401661 E89A030000 call 00401A00 LS inicialización 
<-- del cuadro de 
<-- diálogo 
:00401666 C745FC00000000 mov [ebp-04], 00000000 
:0040166D 8D8D44FFFFFF lea ecx, dword ptr [ebp+FFFFFF44] 


* Reference To: MFC42.Ordinal:09D2, Ord: 09D2h 


:00401673 E8C8040000 Call 00401B40 <-- visualización 
<-- de la ventana de advertencia 

:00401678 8D45DO lea eax, dword ptr [ebp-30] 

:0040167B 50 push eax 


* Reference To: KERNEL32 . GetModuleHandleA, Ord:0126h 


:0040167C0 FF1504204000 Call dword ptr [00402004] 
:00401682 8985E4FEFFFF mov dword ptr [ebp+FFFFFEE4], eax 
00401688 8D8DOOFFFFFF lea ecx, dword ptr [ebp+FFFFFFOO] 
:0040168E 51 push ecx 

:0040168F 8B95E4FEFFFF mov edx, dword ptr [ebp+FFFFFEEA4] 
:00401695 52 push edx 


* Reference To: KERNEL32.GetProcAddress, Ord: 013Eh 


:00401696 FF150C204000 Call dword ptr [0040200C1 
:0040169C 8945A4 mov dword ptr [ebp-5C], eax 

-0040169F 8D850CFFFFFF lea eax, dword ptr [ebp+FFFFFFOC] 
:004016A5 50 push eax 

:004016A6 8B8DE4FEFFFF mov ecx, dword ptr [ebp+FFFFFEE4] 
:004016AC 51 push ecx 
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Al depurar esta parte del código, se observará que el cuadro de diálogo se muestra 
invocando la función en la dirección 00401B40 con la instrucción CALL 00401B40 (en la 
dirección 00401673). Como siempre, cuanto menos código se modifique, tanto mejor, así 
que bastaría con saltarse sencillamente la instrucción CALL para evitar mostrar la ventana 
de advertencia. 


Con objeto de evitar aplicar innecesariamente la instrucción NOP a CALL, se puede 
sobrescribir ésta con una instrucción JMP de longitud idéntica a la instrucción siguiente, 
esto es, con valor E900000000h. 


Edición hexadecimal del programa 


Si se aplicasen las modificaciones al programa mediante un editor hexadecimal, el 
propio programa reconocería esta alteración. Con objeto de evitar tal situación, deberá 
examinarse el algoritmo que realiza la comprobación de integridad de los datos. 


Como probablemente ya haya observado el lector, resulta imposible utilizar aquí 
referencias a cadenas de caracteres. Deberá, por tanto, comenzarse la búsqueda con la lista 
de funciones importadas. El que en dicha lista figuren funciones nada sospechosas, como 
CreateFileA y ReadFile, indica que el algoritmo en cuestión debe basarse en la 
comprobación del contenido de la memoria. Desgraciadamente no sucede así. Puesto que 
éste es un ejercicio práctico, se ha optado por comprobar la integridad de los datos a partir 
del fichero en disco, mucho más fácil de detectar y anular. 


Esto demuestra que en ocasiones la utilización de trucos sencillos (en este caso, 
ocultar las cadenas de caracteres y las funciones importadas al desensamblador) puede 
distraer fácilmente la atención del cracker a algo completamente distinto (por otra parte, y 
esto es sólo un ejemplo, la mayoría de los crackers utilizarán un punto de corte al acceso a 
memoria). 


Seguidamente se tratará de localizar el algoritmo que realiza la comprobación de la 
integridad de los datos. Lo descubierto hasta ahora indica que probablemente emplee la 
función CreateF1i1eA, lo que conduce a definir el punto de corte a esta función. 

bpx CreateFileA 

El programa parece estar protegido frente a este tipo de ataque puesto que reconoce 
un punto de corte bpx. Se probará con un punto de corte hardware. El mandato siguiente 
define el punto de corte bpm al comienzo de la función CreateFilea: 


bpm CreateFileA x 


Aparecerá SoftICE. Púlsese F12, la herramienta se situará en la dirección 0401779. 
Muy próxima a la dirección en la que se han efectuado cambios para suprimir la ventana 
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de advertencia. Prosígase depurando el programa evitando el uso de puntos de corte. Al 
hilo de esta operación se puede observar un sencillo truco para ocultar funciones 
importadas a un desensamblador, ya mencionado en el capítulo 3 al describir las técnicas 
antidesensamblaje. Este truco se basa en la definición manual de las direcciones de las 
funciones necesarias mientras el programa se está ejecutando. Como estas funciones no se 
reflejan en la tabla importaciones (dicho de otra forma: ninguna de las referencias de la 
tabla importaciones conduce a estas funciones), W32Dasm no puede detectarlas. 
Obsérvese más de cerca este truco con W32Dasm: 


* Reference To: KERNEL32.GetModuleHandleA, Ord: 0126h 


:0040167C FF1504204000 Call dword ptr [00402004] 
:00401682 8985E4FEFFFF mov dword ptr [ebp+FFFFFEE4], eax 
:00401688 8D8DOOFFFFFF lea ecx, dword ptr [ebp+FFFFFFO0] 
:0040168E 51 push ecx 

:0040168F 8B95E4FEFFFF mov edx, dword ptr [ebp+FFFFFEE4] 
:00401695 52 push edx 


* Reference To: KERNEL32.GetProcAddress, Ord:013Eh 


:00401696 FF150C204000 Call dword ptr [0040200C] 

:0040169C 8945A4 mov dword ptr [ebp-5C], eax <--= EAX = 
dirección de la función API CreateFileA 

:0040169F 8D850CFFFFFF lea eax, dword ptr [ebp+FFFFFFOC] 

:004016A5 50 push eax 

:004016A6 8B8DE4FEFFFF mov ecx, dword ptr [ebp+FFFFFEEA4] 

:004016AC 51 push ecx 


* Reference To: KERNEL32.GetProcAddress, Ord:013Eh 


:004016AD FF150C204000 Call dword ptr [0040200C] 
-004016B3 8985F8FEFFFF mov dword ptr [ebp+FFFFFEF8], eax 
<-- FEAX = dirección de la función API ReadFile 


Sigue inmediatamente el algoritmo de comprobación de la presencia de puntos de 
corte bpx (el valor CCh) en la dirección específica de la función. Se comprueba el valor 
CCh en los primeros cuatro bytes de las funciones: 


:004016B9 8B55A4 mov edx, dword ptr [ebp-5C] 
:004016BC 8B02 mov eax, dword ptr [edx] 
:004016BE 8945A8 mov dword ptr [lebp-58], eax <-- EAX 

<-- señala a la función API CreateFileA 
:004016C1 8B8DF8FEFFFF mov ecx, dword ptr [ebp+FFFFFEF8] 
:004016C7 8B11 mov edx, dword ptr lecx] 
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:004016C9 8955AC mov dword ptr [ebp-54], edx <-= EDX 

<-- señala a la función API ReadFile 
:004016CC C785F4FEFFFF00000000 mov dword ptr [ebp+FFFFFEF4A], 
00000000 <-- contador de bytes = 0 
:004016D6 EBOF jmp 004016E7 


* Referenced by a (U)nconditional or (C)onditional Jump at 
Address: 
:00401753 (U) 


:004016D8 8B85F4FEFFFF mov eax, dword ptr [ebp+FFFFFEF4] 

:004016DE 83C001 add eax, 00000001 

:004016E1 8985F4FEFFFF mov dword ptr [ebp+FFFFFEF4], eax 
<-- contador ++ 


* Referenced by a (U)nconditional or (C)onditional Jump at 
Address: 
:004016D6 (U) 


:004016E7 83BDF4FEFFFFO5 cmp dword ptr [ebp+FFFFFEF4], 

00000005 

:004016EE 7D65 jge 00401755 <-- bucle para una 

<-- comprobación progresiva de 
<-- los primeros cuatro 
<-- bytes de la función 

:004016F0 8B8DF4FEFFFF mov ecx, dword ptr [ebp+FFFFFEF4] 

:004016F6 33D2 xor edx, edx 

:004016F8 8A540DA8 mov dl, byte ptr [ebp+ecx-58] 

:004016FC 81FACCOOO000 cmp edx, 000000CC $e 

¿CreateFileA bpx? 

:00401702 7414 je 00401718 

:00401704 8B85F4FEFFFF mov eax, dword ptr [ebp+FFFFFEF4] 

:0040170A 33C9 xor ecx, ecx 

:0040170C 8A4C05AC mov cl, byte ptr [ebp+eax-54] 

:00401710 81F9CC000000 cmp ecx, 000000CC <-- ¿ReadFile 

bpx? 


:00401716 753B jne 00401753 


Examínese ahora la función CreateFileA, donde está definido el punto de corte 
hardware. SoftICE mostrará la dirección 0401779: 


:00401755 8D85E8FEFFFF lea eax, dword ptr [ebp+FFFFFEE8] 
:0040175B 8985FCFEFFFF mov dword ptr [ebp+FFFFFEFC], eax 
:00401761 6A00 push 00000000 
:00401763 6880000000 push 00000080 gas 

FILE ATTRIBUTE NORMAL 
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:00401768 6A03 push 00000003 E= OPEN_EXISTING 
:0040176A 6A00 push 00000000 

:0040176C 6A01 push 00000001 q FILE SHARE _READ 
:0040176E 6800000080 push 80000000 <-- GENERIC_READ 
:00401773 FFBS5FCFEFFFF push dword ptr [ebp+FFFFFEFC] 
:00401779 FF55A4 call [ebp-5C] <-- CALL CreateFileA 
:0040177C 8985BCFEFFFF mov dword ptr [ebp+FFFFFEBC], eax 
:00401782 83BDBCFEFFFFFF cmp dword ptr [ebp+FFFFFEBC] , 
FFFFFFFF <-- ¿valor incorrecto del manejador? 
:00401789 753B jne 004017C6 


Le sigue inmediatamente la función APIReadFile: 


:00401802 6A00 push 00000000 

:00401804 FFBSFCFEFFFF push dword ptr [ebp+FFFFFEFC] 

:0040180A FFB518FFFFFF push dword ptr [ebp+FFFFFF18] 

:00401810 FF75B4 push [ebp-4C] 

:00401813 FFBSBCFEFFFF push dword ptr [ebp+FFFFFEBC] 

:00401819 FF95F8FEFFFF call dword ptr [ebp+FFFFFEF8] ges 
CALL ReadFile 


A continuación se encuentra exactamente lo que se andaba buscando: el cálculo de 
comprobación: 


:0040181F B849184000 mov eaX, 00401849 
:00401824 2D59164000 sub eax, 00401659 
:00401829 8BC8 mov ecx, eax 

:0040182B BF59164000 mov edi, 00401659 
:00401830 81EF00004000 sub edi, 00400000 
:00401836 037DB4 add edi, dword ptr [ebp-4C] 
:00401839 33C0 xor eax, €ax 

-0040183B 33DB xor ebx, ebx 

:0040183D 33F6 xor esi, esi 

:0040183F 8A07 mov al, byte ptr [edi] 
:00401841 F7E6 mul esi 

:00401843 03D8 add ebx, eax 

:00401845 47 inc edi 

:00401846 46 inc esi 

:00401847 E2F6 loop 0040183F <-- HEBX = comprobación 
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:00401849 81FB3374F83A cmp ebx, 3AF87433 <-- Comparación 
entre los 
valores correcto 
y calculado de 
la comprobación 
de integridad 
:0040184F 7453 je 004018A4 <-- bifurcación = programa no 
modificado 


Todo queda claro ahora. Bastará con transformar la bifurcación condicional en la 
dirección 0040184F a una bifurcación incondicional para que el programa nunca perciba 
que se ha modificado. 


Utilización del cargador 


Puesto que el programa comprueba su integridad a partir del fichero en disco, podrá 
utilizarse un cargador para editar su código (o más concretamente, suprimir su ventana de 
advertencia) y evitar con ello la búsqueda y supresión de los mecanismos de comprobación 
de integridad. Puesto que ya ha quedado explicado el procedimiento de supresión de la 
ventana de advertencia, se comenzará con la programación del cargador, 


El cargador transformará la instrucción CALL 00401B40 en la dirección 041673 a 
JMP 00401678. El código será semejante al siguiente (si resultase difícil su 
interpretación, acúdase al capitulo 6 sobre edición del código del programa): 


DWORD OverwriteAddress,NOBW; 
PROCESS INFORMATION ProcessInfo; 
STARTUPINFO StartInfo; 


Startinfo.cb = sizeof (StartInfo); 
StartIinfo.lpReserved = NULL; 
StartInfo.lpDesktop = NULL; 
StartInfo.lpTitle = NULL; 
StartIinfo.dwFlags = 0; 
StartInfo.cbReserved2 = 0; 
StartInfo.lpReserved2 = NULL; 


OverwriteAddress = 0x00401673; // dirección de memoria 
// donde se aplican los 
// cambios 

BYTE OverwriteValue[5] = (0xE9,00,00,00,00); // valor 


// escrito en la 
//ubicación dada de memoria 
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CreateProcess 
("CRCMe.exe” , NULL, NULL, NULL, false, CREATE_SUSPENDED, NULL, 
NULL, StartInfo, £ProcessInfo); // crea proceso de la 


// aplicación dada 
// con el parámetro 
//CREATE_SUSPENDED, 
// indicando que el 
// programa se 
// cargará en memoria 
// sin ejecutarse 
WriteProcessMemory 
(ProcessInfo.hProcess, (LPVOID) OverwriteAddress, 
sOverwriteValue,sizeof (OverwriteValue) ,£€NOBW) ; 
// se aplican los cambios en memoria 
ResumeThread (ProcessInfo.hThread); // ejecuta la 
// aplicación 


También se puede crear fácilmente un cargador con RISC*s Process patcher. Éste 
sería un ejemplo de fichero de mandatos: 


¡ZemoZz 's CRCMe crack by ZemoZ 


F=CRCMe.exe: 
O=CRCLoadMe .exe: 
P=004015CF/E8,CC,04,00,00/E9,00,00,00,00: 


$ 


Por último, éste sería el código del programa en lenguaje C++: 


BOOL CCRCMeDl1g: :OnTnitDialog() 


( 


CDialog::OnInitDialog(); 


SetIcon (m_hIcon, TRUE); // definición de icono 
// grande 
SetIcon (m_hIcon, FALSE); // definición de icono 
// pequeño 


/**k*x** guardando la secuencia de caracteres para que 
no queden visibles en la lista de referencias de 
W32Dasm. Se pueden leer todas las secuencias de 
caracteres fácilmente con un editor hexadecimal como 
Hiew:- (HAHAHA ARAS 
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BYTE Library[9] = 
[0x4B,0x65,0x72,0x6E,0x65,0x6C,0x33,0x32,0); 

BYTE APIC[12] = 
(0x43,0x72,0x65,0x61,0x74,0x65,0x46,0x69,0x6C,0x65, 0x4 
1,0); 

BYTE APIR[9] = 
(0x52,0x65,0x61,0x64,0x46,0x69,0x6C,0x65,0); 

BYTE FileName[10] = 
(0x43,0x52,0x43,0x4D,0x65,0x2E,0x65,0x78,0x65,0); 


BYTE BPxfailed[] = ('B','P','X',' ','b!,'x','e',la', 
Y PA ME ab, MESA e TEN tal, Tar, 1 ta! 0): 
BYTE Openfailed[] = ('F",!11,'1*,"e!,! ', e, ta!, tn, 
os Hor MBA, UA MEN, E¿FOM, pr Met, Ip ey Mar, 

0); 

BYTE CRCOok [] = (10, ht, te!,! E E PL > LP A 
A A CALEW, O Ay SY" o Ha, La gn, di Ek 
LO y PER 00 PIB an a Uy LOAN BEN, 
1i1,"e','d',0); 

BYTE (ROfaileal] = (WTF, Bl, 16r,1 0, 0pr, 581, Vg", gl, 
A A: Py Est, Mor, Tar, fet, E MR, Eat, SN, A A 
BT, el, ter, ta ,! A IS A A AS E AA AA 
0); 

ImportantArea: 


CNag nag; // CNag - tipo de cuadro de diálogo 
// estándar 
nag.DoModal(); // visualización del cuadro de diálogo 


HMODULE handle = GetModuleHandle ( (char*) Library) ; 
// kernel32 ImageBase 
FARPROC Create = GetProcAddress (handle, (char*) APIC) ; 
// CreateFileA 
FARPROC Read = GetProcAddress (handle, (char*) APIR) ; 
// ReadFile 


byte CMem[4] ,RMem[4]; 
memcpy (8SCMem, Create, sizeof CMem) ; 
memcpy (£RMem, Read, sizeof RMem) ; 


/**x*kx*x** Comprobación de la presencia de un punto de 
corte bpx en los primeros cuatro bytes de las 
funciones CreateFileA y ReadFile***x*x**x*/ 


for (int 1 = 0; 1 < 57 14+) 


( 


if (CMem[i] == OxCC || RMem[i] == 0xCC) 


( 
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SetD]gTtemText (IDC_CRCSTATUS, (char*) BPX£ailed) ; 
return TRUE; 


) 


DWORD Address = (DWORD) £FileName [0] ; 
HANDLE File; 
DWORD NOBR; 


asm 


( 

push 0 

push FILE ATTRIBUTE_NORMAL 
push OPEN_EXISTING 

push 0 

push FILE SHARE READ 

push GENERIC_READ 

push Address 

call Create 

mov File, eax 


// File = CreateFile ((char*) FileName, GENERIC_READ, 
FILE SHARE_READ,NULL,OPEN_EXISTING, 
FILE ATTRIBUTE_NORMAL, NULL) ; 

// obtención del manejador del fichero 


if (File == INVALID HANDLE VALUE) 


SetD1gItemText (IDC_CRCSTATUS, (char*) Openfailed) ; 
return TRUE; 


) 


DWORD FileSize = GetFileSize (File,NULL) ; 
BYTE *pMem = new BYTE [FileSizel; // asignación de 

// memoria 
Address = (DWORD) £NOBR; 


asm 


( 


push 0 

push Address 
push Filesize 
push pMem 
push File 
call Read 


VA ReadFile (File, pMem, Size, £NOBR, NULL) ; // carga del 
// fichero en memoria 
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/****x***cálculo de la comprobación de 
integridad*****x*x*/ 


mov eax,offset EndImpArea 
sub eax,offset ImportantArea // EAX = longitud 
// de los datos 
// comprobados 

mov ecx,eax 
mov edi,offset ImportantArea 
sub edi,400000h 
add edi,pMem // EDI = puntero a los datos 

// comprobados 


xor eax,eax 

xor ebx,ebx 

xor esi,esi 

Looop: 

mov al,byte ptr ledil  // carga de datos 
mul esi // multiplicación sencilla 

add ebx,eax // envío de resultados a EBX 
inc edi // siguiente byte 

inc esi // incrementando ESI 

loop Looop 

// --> EBX = comprobación 


EndImpArea: 
cmp ebx, 3AF87433h 
je Ok 
ll 
SetDlgItemText (IDC_CRCSTATUS, (char*) CRCfailed) ; 
delete pMem; 
return TRUE; 


Ok: 

SetDlgltemText (IDC_CRCSTATUS, (char*) CRCok) ; 
delete pMem; 

return TRUE; 


CAPÍTULO 10 


INFORMACIÓN COMPLEMENTARIA 
SOBRE EL CRACKING 


—————————— —_————__—_—_—_————— 


ORIGEN Y DIFUSIÓN 


Resulta imposible saber exactamente cuándo y cómo comenzó el cracking. Aquellas 
ciencias en las que se basa, como la ingeniería inversa, han existido desde el comienzo de 
la informática. Todo ello dificulta mucho señalar cuándo apareció exactamente el término 
“cracking”. 


Antes de la existencia de los lenguajes actuales de programación de alto nivel, gozaban 
de gran respeto y prestigio en el mundo de los sistemas de información aquellos desarrolladores 
que se dedicaban a programar en ensamblador. Puesto que resultaba muy dificil obtener 
información en este campo, se veía muy reducido el número de dichos programadores, la 
mayoría trabajaban como expertos para grandes empresas, si se les compara con el número que 
hay hoy en día. 


Ahora bien, han cambiado muchas cosas desde entonces: todo se ha simplificado 
significativamente desde que aparecieron los lenguajes de programación de alto nivel, El 
desarrollo se hizo mucho más accesible a un mayor número de personas por poder prescindir 
perfectamente del ensamblador. Este cambio se hizo aún mucho más intenso desde que 
aparecieron los sistemas operativos basados en la plataforma Win32, con la que también 
aparecieron lenguajes y técnicas de programación mucho mejores. Esto significó el final 
definitivo a la necesidad que los usuarios tenían de conocer ensamblador y las tecnologías de 
información como tales. Hoy en día existen técnicas y programas que permiten incluso a un 
completo principiante programar lo que de otro modo eran aplicaciones bastante complicadas. 
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No por ello el público perdió interés ni por el ensamblador ni por otros temas 
relacionados con éste. En el IRC (en inglés, “Information Relay Chat”, lugar en la red donde 
gente de todo el mundo busca cierto tipo de información, puede reunirse e intercambiar sus 
experiencias), aparecieron varios canales de información sobre esta materia. Sus usuarios 
pronto observaron que podrían llegar mucho más lejos compartiendo su conocimiento que 
simplemente programando, ése fue el principio de la edición de sofiware. En aquella época, el 
software no estaba nada preparado para algo así, tampoco lo está hoy en día realmente, de 
manera que resultaba facilísimo suprimir los diferentes tipos de protección de entonces. Ello 
contribuyó a que aumentara el número de personas interesadas en estas técnicas, con lo que 
empezó a conformarse progresivamente un conjunto de procedimientos y métodos nuevos al 
que genéricamente se denomina Cracking. 


Puesto que el deseo de conocimiento de las personas no tiene límite, el IRC pronto se 
quedó pequeño para poder entrenar a los principiantes e intercambiar grandes cantidades de 
información. Los interesados comenzaron a organizarse en grupos, pronto aparecieron las 
primeras páginas en Internet centradas en el cracking y su formación. Uno de los líderes en este 
campo fue el grupo denominado +HCU (Higher Cracking University), organizado en abril de 
1996 por una persona que se ha convertido en una leyenda en este campo denominada +ORC 
(Old Red Cracker). Fue el primero en definir los principios del cracking tal como los 
conocemos hoy en día. +ORC y sus alumnos entrenaron a miles de programadores, 
codificadores, crackers y especialistas en ingeniería inversa por todo el mundo que hoy en día 
están creando grupos nuevos sobre cracking, programación e ingeniería inversa difundiendo así 
su conocimiento y experiencia a otras generaciones, 


En la primavera de 1998 desapareció el misterioso “Old Red Cracker”, desde entonces 
nadie ha vuelto a oír hablar de él (o de ella, ¿quién sabe?). No existe ningún tipo de 
información sobre su persona (nacionalidad, origen, etc.), lo cual es bien triste puesto que no 
sólo a muchos crackers, sino también a muchos desarrolladores les hubiera gustado conocer la 
identidad de la persona que dio origen a todo este asunto. Por otra parte, probablemente +ORC 
ya contara con esta eventualidad y pudiera querer mantener su identidad en secreto. Existen 
unas cuantas páginas en Internet dedicadas a investigar y encontrar todo tipo de información 
sobre su persona. Hay un par de hipótesis verdaderamente interesantes en estas páginas que 
merecen la pena leerse (aunque sólo sea por entretenimiento). 


CRACKERS 


Puede afirmarse en general que los crackers suelen ser estudiantes interesados en la 
tecnología de la información (si bien existen varias excepciones). Una vez que estas 
personas eligen su profesión en el mismo campo, normalmente también se especializan en 
algún otro campo similar, como la programación en ensamblador, la criptografía, etc. 


Generalmente su conocimiento del cracking parte de su habilidad para programar en 
ensamblador, algunos de ellos desarrollan ambas aptitudes simultáneamente. 
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Paradójicamente para muchos de los crackers más destacados, el cracking constituye tan 
sólo una distracción, estudian algo completamente distinto (química, economía...). 


CRACKERS Y GRUPOS CONOCIDOS 


Resulta prácticamente imposible enumerar la lista de todos los crackers y grupos de 
cracking que existen en el mundo. Se destacarán aquí los nombres de los más importantes 
y se aportará información sobre ellos siempre que sea posible. Naturalmente, muchos 
grupos de cracking mantienen la identidad de sus miembros en secreto, incluso si este 
autor supiera esta información, no podría publicarla. Las páginas en Internet de los 
crackers y de los grupos de cracking también suponen otro obstáculo al estar cambiando la 
mayoría de ellas constantemente de ubicación y dificultar así enormemente su búsqueda. 


Podrán hallarse aquí crackers que ya no realizan ninguna actividad o grupos de 
cracking que ya no existen. No obstante, su estudio no constituye ninguna pérdida de 
tiempo. Ya se ha mencionado la importancia histórica de estas personas: seguir su 
trayectoria constituye un aspecto importante para entender lo que realmente significa el 
cracking. 


La selección realizada de algunos grupos actuales de cracking no ha seguido ningún 
criterio específico. Se recoge información sobre los que el autor ha conocido directa O 
indirectamente. Constituye una lista bastante breve que el lector podrá ampliar con otros 
grupos que localice en el futuro. 


+HCU 


Seguramente no será necesario presentar este grupo a nadie que alguna vez haya 
tenido interés en la ingeniería inversa o en el cracking. Ya se mencionó al principio de este 
capítulo la importancia de este grupo; no obstante, a continuación se ofrece información 
complementaria sobre +HCU, 


Probablemente la palabra “grupo” no represente adecuadamente la situación real. Su 
propio nombre —Higher Cracking University — lo indica con mayor precisión. Constituye 
una escuela virtual integrada por muchos alumnos del famoso programador y especialista 
en ingeniería inversa FORC. 


Uno de los elementos básicos que +ORC creó para poder entrenar a este grupo fue 
el sobradamente conocido servidor de Internet con dirección fravia.org, a menudo 
referido como la página Fravia sobre ingeniería inversa (denominada a partir del 
sobrenombre del fundador y miembro de +HCU, Fravia+). Este servidor, especializado en 
el desarrollo con ensamblador, ingeniería inversa y cracking, estuvo actualizado durante 
varios años con información aportada por alumnos y otras personas interesadas en este 
campo. Si bien sus páginas se replicaron en otros servidores, sólo una de estas réplicas 
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sigue actualizándose: tsehp.cjb.net. Buena parte de los miembros de +HCU crearon 
sus propios grupos de cracking y servidores en Internet para seguir entrenando a nuevas 
generaciones de especialistas en ingeniería inversa y difundir las ideas del fundador, 
+ORC, quien pretendió que el conocimiento y la información se difundieran libremente. 


Bien podrían tomar ejemplo algunos grupos de cracking alejados de la difusión del 
conocimiento y empeñados por contra en la distribución de software ilegal y en la 
anulación de sus protecciones. Algunas personas sólo interesadas en probar la última copia 
ilegal de algún juego sí que estarán interesadas en la existencia de este tipo de crackers; no 
se olvide, sin embargo, que no fue esto lo que +ORC enseñó a sus alumnos. Lo que él 
enseñó fue a compartir su conocimiento y no a anular el software para distribuirlo de 
forma ilegal. No obstante, ésta es una cuestión abierta acerca del uso y aplicación del 
cracking. 


Immortal Descendants 


Este grupo se creó en 1995, los fundadores originales eran miembros de un grupo 
IRC denominado Deadmen . Society: TROYBOY, Volatility, Raven, Mortis y Yakuza. 
Conforme fueron ganando experiencia y conocimientos, decidieron crear su propio grupo 
de cracking denominado Immortal Descendants. 


Ahora bien, su entusiasmo desapareció rápidamente cuando Raven, Mortis y 
Yakuza abandonan el grupo. TROYBOY y Volatility no aguantaron mucho más tiempo y 
el grupo llegó a poner fin a sus actividades. 


Siete meses más tarde, Volatility volvió a trabajar de nuevo y el grupo se fortaleció 
con nuevos miembros. La composición del grupo cambió varias veces a lo largo del tiempo 
y llegó a incluir a individuos bien conocidos dentro de este campo. 


El grupo desapareció definitivamente el 18 de octubre de 2001 debido a la mala 
situación en el campo. Es una pena puesto que constituía un grupo verdaderamente 
profesional que realizaba contribuciones importantes al mundo de la ingeniería inversa y 
del cracking y que no sólo ayudaba a miles de principiantes sino a crackers mucho más 
experimentados de todo el mundo. Se hicieron famosos por una bien conocida guía 
denominada “Cracker's notes” y por los miles de documentos y otras guías que fueron 
añadiéndose progresivamente a su servidor durante muchos años. 


La última lista conocida de los miembros del grupo facilitada por él mismo 
comprendía a: amante4, SantMat, Lord Soth, alpine, tHE ANALYST, Muad'Dib, visionz, 
defiler, [yAtEs], extasy. 
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Messing in Bytes — MiB 


Inicialmente, el objetivo principal de los fundadores de este grupo, Icedragon y 
+Cruehead, consistía en renovar un canal IRC denominado *fcracking, ya en desuso. 
Rápidamente se les unió un cracker denominado Badman y decidieron ponerse a trabajar 
juntos con un nombre distinto. Éste fue el origen del grupo de cracking denominado 
Messing in Bytes. 


No hay duda alguna de la profesionalidad de este grupo. Los mundialmente 
conocidos “crackmes”, de +Cruehead, que sirvieron de ayuda a muchos principiantes de 
todo el mundo, son una buena prueba de ello. El lector ya habrá apreciado lo útiles que 
resultan estos “crackmes” en el entrenamiento sobre cracking realizado en el capítulo 
anterior. 


Si bien no se ha anunciado oficialmente la finalización de las actividades del grupo, 
la última actualización de sus páginas en Internet data del 3 de mayo de 1999. 


Miembros de este grupo: Icedragon, +Cruehead, Badman, cTT, Pero, ¡NCuBuS++. 


Crackers in Action — CIA 


Este gran grupo se hizo popular sobre todo gracias al gran número de excelentes 
guías que publicaron sus miembros. Se pueden encontrar en Internet colecciones enteras de 
ellas que merece la pena leerse. 


El autor no ha podido encontrar información sobre cómo se fundó el grupo ni cómo 
finalizaron sus actividades. Algunos de sus miembros más conocidos son: The Keyboard 
Caper, H3lISp4wn, Z-Wing, DarkShadow, DnNuke, iNNU3Ndo, Northpole, Zee, 
ByteBurn, dbCooper, Dya-Blo, Excelsior, Giggling Granny, y algún otro más. 


Phrozen Crew 


Este grupo ya lleva trabajando hace tiempo y debe resultar familiar a quienes hayan 
intentado alguna vez obtener algún crack en Internet. Es uno de los grupos con mayor 
número de cracks de todo tipo de software del mundo, algunos de ellos con algoritmos de 
protección realmente complicados. Es sin duda el mayor especialista en este campo. 


Este grupo también ha publicado algunos manuales y material de estudio bastante 
buenos. Merece la pena destacar una famosa compilación de números de serie, 
contraseñas, etc. de programas de uso compartido denominada Oskar. 
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United Cracking Force 


De este grupo se puede afirmar básicamente lo mismo que ya se ha dicho del grupo 
anterior: es una leyenda con una lista de miembros más legendaria aún si cabe que lo dice 
todo: :MARQUIS:, Lordbyte, Xoanon, G-RoM, Lorian, t00nie, netking, BunteR, [Jakel, 
RegoR, Stone, Dark Stalker, Hendrix, SHamPster, _Shaman, RyDeR_H0O0k!, foSSil, Sun- 
Tzu, Nobody, Quantico, tHeRain, Sp0t, y algún otro más. 


DEViANCE 


No parece necesario presentar este grupo a nadie que haya encontrado alguna vez 
una copia pirateada de algún juego en formato ISO. Este grupo, junto a otros como 
FairLight o Razor 1911, constituye el mayor grupo distribuidor de software ilegal en 
Internet. Su actividad se centra principalmente en juegos, el número de sus cracks alcanza 
varios cientos si no más. 


Ebola Virus Crew 


Con tan inusual nombre, este grupo también tiene su importancia. Ha producido un 
buen número de manuales, cracks y otros recursos. 


Este grupo parece bastante prometedor y, junto a otros como DEViANCE y 
Evidence, figura entre los más populares hoy en día. 


Algunos de sus miembros son: +ViPeR+, ApAthy, Ebony Tears, FireAngel, 
fLATEr, G-Max, INCREDIiBLE FiGHTER, IncubatiOn, Julio El Negro, JumpBull, Lord 
Spectre, y algún otro más. 


Evidence 


Este popular grupo se formó en febrero de 2001. Desde entonces tanto la lista de sus 
miembros como los líderes del grupo han cambiado varias veces y el grupo se ha 
enfrentado a distintos problemas. 


No obstante, todo parece más estable ahora según se deduce de su propia 
productividad. Han codificado cerca de 200 cracks y publicado un buen número de guías 
en un período de seis semanas. Su trabajo es bastante completo, cumple su propio 
principio: “calidad en vez de cantidad”. 


A no ser que el grupo atraviese problemas de carácter interno, con seguridad se 
volverá a oír hablar de él en el futuro. 
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Da Breaker Crew 


Este grupo se creó en 1998 con un equipo de tan sólo cuatro miembros. 
Últimamente se ha vuelto muy popular, entre otras cosas, por su motor universal de 
cracking y su librería complementaria de cracks denominada X-Brain. 


El grupo mantiene la lista de sus miembros en secreto. Esperemos que su principio 
“un grupo una familia” les ayude a mantener el éxito. 


RECURSOS EN INTERNET 


Cracking e ingeniería inversa 


o http://tsehp. cjb.net/ Página Fravia sobre ingeniería inversa, la última 
réplica actualizada de la legendaria +HCU, actualmente administrada por Tsehp. 
Aunque la calidad de la página ya no sea comparable a lo que fue cuando todavía 
estaba en funcionamiento, merece la pena definitivamente visitarla. 


o http://www. reverse-engeneering.de/ “AntiCrack” —Alemania— 
servidor de Internet bastante nuevo dedicado al cracking y al anticracking, con una 
enorme cantidad de guías, herramientas, enlaces y otra información actualizada. 


o http://greythorne.cjb. net/ “Greythorne The Technomancer” 
— Greythorne— otro cracker de la vieja escuela. Deben visitarse las páginas 
basadas en los principios de +ORC aunque ya no se actualicen con frecuencia 
(o nada en absoluto). Siempre se podrán encontrar antiguos manuales aunque 
bastante buenos. 


o http://zor.org/krobar Colección Krobar, resulta obligado visitar estas 
páginas. Se podrán encontrar aquí colecciones enteras de manuales, un gran 
número de referencias y otro tipo de material claramente organizado en campos 
individuales. 


e http://hammer. prohosting -. com/-zoum/main. html Constituye el 
motor de búsqueda del especialista en ingeniería inversa: un formidable catálogo 
con más de 1.000 manuales dedicados a la ingeniería inversa. 


o http://hculinux.cjb.net/tools html Herramientas linux sobre 
ingeniería inversa. Si se está interesado en la ingeniería inversa y linux, estas 
páginas están dedicadas a ambos temas. 
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e  http://www.fortunecity.de/wolkenkratzer/balut/905/ 
“LW2000 [CIA] Tutorials”, páginas de uno de los miembros del grupo 
Crackers in Action con una buena cantidad de información y material 
interesante, sobre todo manuales. 


o  http://ww.yates2k.net/ “yaTeS 2K”, interesantes páginas dedicadas a 
la ingeniería inversa. Se puede encontrar aquí varios manuales e información no 
sólo para principiantes. 


Programación 


e  http://webster.cs.ucr.edu/ The Art of Assembly”, su propio nombre 
lo dice todo (en castellano, “El arte del ensamblaje”); toda persona interesada en 
la programación con ensamblador tendrá interés en esta página. 


e  http://win32asm.cjb.net/ “lezelion”s Win32 Assembly HomePage”, sin 
duda una de las mejores páginas en Internet dedicadas a la programación del 
ensamblador Win32. Recoge todo lo que resulta necesario conocer, tanto para el 
principiante como para el usuario avanzado. Gracias a lo bien organizado que está 
su material de estudio, puede el usuario avanzar paso a paso en la programación 
con el ensamblador Win32, sobre todo en el caso de los principiantes y de que 
quiera aprender a programar en este lenguaje; para tal objetivo, este servidor 
supone una gran ayuda. 


e  http://ww.anticracking.sk/EliCZ/index.htm/ página de inicio 
de EliCZ, uno de los mejores programadores checos y de todo el mundo con el 
sobrenombre de EliCZ. Las páginas están dedicadas a la programación en 
ensamblador, constituye otra gran fuente de recursos con numerosos ejemplos 
sencillos. 


e http://codeinjection.cjb.net/ “Pages of Code Injection”, conforme 
indica el nombre de estas páginas (en castellano “páginas de inyección de 
código”), aquí se podrá encontrar mucho material dedicado a la transformación de 
código en aplicaciones y programas completos. Puesto que este tema está 
estrechamente vinculado a los compresores y codificadores PE, estas páginas 
resultan recomendables a todos los que intentan programar con tales herramientas. 
Su autor, Lord Rhesus, ha realizado un buen trabajo organizando este servidor. 
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Herramientas 


e http://protools.cjb.net/ “Programmers Tools”, probablemente el 
mayor servidor de herramientas para programadores y especialistas en ingeniería 
inversa. Si se está buscando un programa en concreto, probablemente se encuentre 
aquí. Se podrán descargar programas como W32Dasm o Hiew, ambos no 
pudieron incluirse en el CD adjunto. 


e http://programmersheaven.com/ “Programmers Heaven”, una vez más, 
estas páginas se centran en las necesidades de programador. Al igual que en el 
caso anterior, podrán hallarse aquí numerosas herramientas y utilidades. 


e http://w.thepentagon.com/frog_s print “Frog's Print, 
páginas de la herramienta de antiantidepuración para crackers denominada 
FrogsICE. Se podrá encontrar muchísima información interesante aquí siempre 
que no se utilice Internet Explorer. En caso contrario no se podrá disfrutar de estas 
páginas ya que al autor no le gustan obviamente ciertos productos de Microsoft: 
las páginas no podrán visualizarse con este navegador. 


o http://www.sysinternals.com “Sysinternals”, páginas de una empresa 
denominada Sysinternals, dedicada al desarrollo de herramientas de supervisión. 
Desde aquí se podrán descargar no sólo los programas ya mencionados *File 
Monitor” y “Registry Monitor” (véase el capítulo 8), sino también otros programas 
como “VxD Monitor”, muy útil para supervisar la actividad de las librerías en 
ejecución VxD, así como “Port Monitor”, para supervisar los puertos en uso del 
ordenador. 


e http://ww.bpsoft.com 'BreakPoint Software, Inc.”, servidor de la 
empresa “BreakPoint Software, Inc.”, quien trajera al mundo uno de los editores 
hexadecimales más conocidos para el sistema operativo Windows, denominado 
“Hex Workshop”. 


Referencias 


e http://learn2search.cjb.net/ “Nitallica"s How To Search Site”, 
páginas ideales para quienes todavía no encuentran lo que buscan en Internet. 
Buscar con eficacia constituye obviamente una actividad vital que a menudo se 
infravalora y se malutiliza. Esta página resulta pues recomendable para quienes 
molestan a otras personas preguntando diferentes enlaces. Es imprescindible saber 
cómo buscar. 
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e http://zor.org/nitallica/ “Nitallica”s Useful Links £ URL”s”, una de 
las mayores listas de referencias en Internet. Cuando se busque algo en concreto, 
acúdase a buscar a esta página. 


Grupos de cracking 


e http://geocities.com/Vienna/Opera/5748/index.htm — páginas 
del grupo de cracking Tres2000. 


e http://kickme.to/tnt/ — páginas del grupo de cracking TNT. 


e http://dni.darktech.org/dbc/news.htm -— páginas del grupo de 
cracking Da Breaker Crew. 


o http://evc.to/cracks -— páginas del grupo de cracking Ebola Virus Crew. 


CONSEJOS BÁSICOS DE LOS CRACKERS 


Este libro comenzó con algunas recomendaciones generales dirigidas a los 
programadores sobre cómo proteger sus programas frente al cracking. Ahora toca el turno 
a los consejos hechos para y por crackers. 


Cracking (Lucifer48) 


Para mí el cracking pertenece al campo más general de la ingeniería inversa. Resulta 
absolutamente importante conocer ensamblador perfectamente (todos los crackers debería ser 
desarrolladores). También es importante leer varios artículos sobre el tema. Asimismo 
recomiendo practicar con varios “crackmes”, algunos de ellos son realmente espectaculares; ¡es 
un magnífico ejercicio! Además de saber parchear y depurar, son necesarios un montón de 
conocimientos fundamentales: matemáticas, algoritmos, lenguajes (ASM, C, Pascal, Java, 
Prolog, Caml,...), criptografía, sistemas operativos (no sólo Windows, prueba con linux/unix),... 
(en realidad todo ello forma parte de la informática). 


¡Definitivamente el conocimiento es poder! Para llegar a ser un cracker actúa como 
un cracker. Siempre recuerda que los crackers experimentados te ayudarán con todo lo que 
necesites aprender: IRC, forums, correo electrónico, todo perfecto para comunicarse. No 
malgastes ni un solo día: aprende, aprende, aprende. 
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Aplicación de instrucciones NOP (+ORC) 


No utilices instrucciones NOP a no ser que sea absolutamente necesario, siempre 
suele haber un método mejor. Por ejemplo, se pueden sustituir 2 NOPs con un simple INC 
EAX, DEC EAX o algo parecido. Hay muchos otros recursos que se pueden utilizar en 
vez de un NOP, que, por cierto, resulta bastante sencillo detectar en el código. 


Parchear (MisterE) 


Ya te lo digo desde ahora mismo: detesto parchear. Existen muchas razones por las que 
no debiera parchearse, aunque se dan situaciones en las que no queda otro remedio. Como 
cuando se intenta suprimir una ventana de advertencia de algún programa que no permite 
introducir un nombre o un número de serie, Si puedes introducir un número de serie o registrar 
el programa sin parchearlo, ¡adelante! Si prefieres parchearlo, te encontrarás con problemas 
como la comprobación de integridad CRC u otro tipo de comprobaciones recurrentes. Otro 
problema frecuente cometido por los novatos es que parchean con alguna bifurcación justo 
antes de la invocación a MessageBoxa. El programa pide que te registres, pero lo único que 
se parcheó fue el programa que muestra el mensaje de “registrado” en vez del mensaje “no 
registrado”. 


Pensar como un cracker (rudeboy) 


A los programadores se les enseña que siempre que tengan que realizar una tarea 
más de una vez, deberían crear una función para efectuarla e invocar la función (CALL) 
siempre que se deba realizar. 


Hoy en día, la mayoría de los programas que utilizan una combinación de nombre y 
número de serie comprueban el código de registro al menos en dos ocasiones: una cuando 
se introduce y otra, cuando el programa arranca, Por esta razón, el programador 
normalmente invoca una función para comprobar la validez. Y normalmente esta función 
será invocada siempre que se compruebe el código. 


Así que si se tiene que parchear la función invocada con objeto de comprobar la 
validez de tu número de serie, siempre se mostrará como válido cuando el programa realice 
su comprobación. 


Las técnicas aquí empleadas no sirven para anular programas que utilicen una 
combinación de nombre y número de serie. Ten un horizonte de miras amplio, estas técnicas 
también se pueden utilizar con muchos otros tipos de protección. Hay veces, por ejemplo, que 
una función se encarga de comprobar la fecha o de mostrar una ventana de advertencia. 
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Herramientas (rudeboy) 


No te limites a una sola herramienta, utiliza SoftICE, W32DASM, IDA y cualquier 
otra conjuntamente. La información obtenida por una de ellas suele servir para las otras. 


CAPÍTULO 11 


SECCIÓN DE REFERENCIA 


INSTRUCCIONES BÁSICAS EN ENSAMBLADOR 
LEA 
Descripción: esta instrucción guarda la dirección de “fuente” en “destino”. 
Sintaxis: LEA destino, fuente 


Ejemplo: PS EAX, variable — guarda la dirección de la variable en el registro 


Operación: variable_destino = devariable2_fuente 


MOV 


Descripción: esta instrucción guarda el contenido de “fuente” en “destino”. 

Sintaxis: MOV destino, fuente 

Ejemplo: MOV EAX, EDX — guarda el valor del registro EDX en el registro EAX. 
MOV EAX, 123h— guarda el valor 123h en el registro EAX. 


Operación: variable_destino = variable2_fuente 
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MOVSX 


Descripción: esta instrucción guarda el contenido de “fuente” en “destino” con 
extensión de signo. Esto es, los bits que no se hayan utilizado de “destino” en la copia 
toman el valor del bit de signo de “fuente”. 


Sintaxis: MOVSX destino, fuente 


Ejemplo: MOVSX EAX, 123h — almacena el valor 123h en el registro EAX y 
guarda en los bits restantes el bit de signo del valor 123h. 


MOVZX 


Descripción: esta instrucción guarda el contenido de “fuente” en “destino” con 
extensión cero. Esto es, los bits que no se hayan utilizado de “destino” en la copia toman 
el valor de cero. 


Sintaxis: MOVZX destino, fuente 


Ejemplo: MOVZX EAX, 123h — guarda el valor 123h en el registro EAX y cambia 
a cero los bits no utilizados en la operación. 


MOVSBI MOVSW/ MOVSD 


Descripción: esta instrucción guarda un byte (MOVSB), palabra (MOVSW), o 
doble palabra (MOVSD) de la dirección DS:EST a la dirección ES:EDI. Los registros ESI 
y EDI se extienden o reducen según la longitud de los datos transmitidos y del “Mag” DF. 

Sintaxis: MOVSB / MOVSW / MOVSD 


Ejemplo: MOVSB — guarda un byte de la dirección DS:ESI en la dirección 
ES:EDL 


MOVSW - guarda una palabra de la dirección DS:ESI en la dirección ES:EDI. 


MOVSD — guarda una doble palabra de la dirección DS:ESI en la dirección 
ES:EDL. 
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LODSB | LODSW | LODSD 


Descripción: esta instrucción guarda un byte (LODSB), palabra (LODSW), o 
doble palabra (LODSD) de la dirección DS:ESI en la parte correspondiente del registro 
EAX. El registro ESI se extiende o reduce según la longitud de los datos transmitidos y 
del “flag” DF. 

Sintaxis: LODSB / LODSW /LODSD 

Ejemplo: LODSB — guarda un byte de la dirección DS:ESI en el registro AL. 

LODSW - guarda una palabra de la dirección DS:EST en el registro AX. 


LODSD — guarda una doble palabra de la dirección DS:ESI en el registro EAX. 


STOSB | STOSW | STOSD 


Descripción: esta instrucción guarda el contenido del registro AL (STOSB), del 
registro AX (STOSW), o del registro EAX (STOSD) en la dirección ES:EDI. El registro 
EDI se extiende o reduce según la longitud de los datos transmitidos y del “flag” DF. 

Sintaxis: STOSB / STOSW / STOSD 

Ejemplo: STOSB — guarda un byte de la dirección DS:EDI en el registro AL. 

STOSW - guarda una palabra de la dirección DS:EDI en el registro AX. 


STOSD — guarda una doble palabra de la dirección DS:EDI en el registro EAX. 


REP 


Descripción: prefijo de instrucción aplicable a las instrucciones con caracteres 
(STOSB, W, D, LODSB, W, D, MOVSB, W, D). Si el prefijo se define antes de una 
instrucción, esta instrucción se repetirá y el registro ECX funcionará como contador. El 
valor del registro ECX disminuye en uno con cada repetición. La repetición finaliza 
cuando el valor del registro ECX llega a cero. En caso de una instrucción REP 
condicionada (REPZ, REPNZ), también se comprueba el “flag” ZF. 


Sintaxis: REP instrucción 
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Ejemplo: MOV ECX, 5 


REP STOSB — repite cinco veces (ECX) guardando el valor del registro AL en la 
dirección ES:EDI; el valor de EDI cambia con cada repetición (véase la instrucción 
STOSB). 


LOOP 


Descripción: esta instrucción permite la construcción de ciclos (también 
condicionados utilizando instrucciones LOOP especiales); el registro ECX se utiliza 
como contador del número de ciclo. El valor del registro disminuye en uno cada vez que 
se ejecuta la instrucción LOOP y, excepto cuando sea cero, realice una bifurcación a la 
dirección indicada (en el caso de la instrucción LOOP condicionada, también se 
comprueba la condición específica). Cuando el registro ECX sea cero, el proceso 
continúa en la instrucción siguiente a LOOP. 


Sintaxis: LOOP dirección 

«Ejemplo: MOV ECX, 5 

Address: MOV [EAX], ECX 
INC EAX 


LOOP dirección — se repetirá cinco veces (ECX) aquella parte del código entre 
la instrucción LOOP y la etiqueta de dirección (esto es, instrucción MOV [EAX], ECX y 
INC EAX). 


NOP 


Descripción: la instrucción NOP (“No Operación”) no ejecuta cierta operación. 


Sintaxis: NOP 


AND 


Descripción: esta instrucción realiza una conjunción lógica (Y lógico) entre 
“fuente” y “destino”, bit a bit y guarda resultado en “destino”, 
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Sintaxis: AND destino, fuente 


Ejemplo: AND EAX, EDX - realiza una conjunción lógica entre los valores de los 
registros EAX y EDX y almacena el resultado en el registro EAX. 


AND EAX,3Ah — realiza una conjunción lógica entre el valor del registro EAX y 
el valor 3Ah; guarda el resultado en el registro EAX. 


Operación: variable. destino = variable_destino «e variable2_fuente 


OR 


Descripción: esta instrucción realiza una suma lógica (O lógico) entre “fuente” y 
“destino”, bit a bit y guarda resultado en “destino”. 


Sintaxis: OR destino, fuente 


Ejemplo: OR EAX, EDX - realiza una suma lógica entre los valores de los 
registros EAX y EDX y almacena el resultado en el registro EAX. 


OR EAX, 3Ah — realiza una suma lógica entre el valor del registro EAX y el 
valor 3Ah; guarda el resultado en el registro EAX. 


Operación: variable_destino = variable_destino /variable2_fuente 


XOR 


Descripción: esta instrucción realiza la función lógica de no equivalencia (sum 
mod 2) entre “fuente” y “destino”, bit a bit y guarda resultado en “destino”. Esta función se 
utiliza frecuentemente al codificar datos. 


Sintaxis: XOR destino, fuente 


Ejemplo: XOR EAX, EDX - realiza la función lógica de no equivalencia entre los 
valores de los registros EAX y EDX y almacena el resultado en el registro EAX, 


XOR EAX, 3Ah — realiza la función lógica de no equivalencia entre el valor del 
registro EAX y el valor 3Ah guarda el resultado en de registro EAX. 
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XOR EAX, EAX — realiza la función lógica de no equivalencia entre dos valores 
idénticos (en este caso los valores guardados en el registro EAX); el resultado de esta 
operación será siempre cero. 


Operación: variable_destino = variable_destino ” variable2_fuente 


NOT 


Descripción: esta instrucción realiza la inversión de todos los bits de “destino” y 
guarda resultado en “destino” (constituye su propio complemento). 


Sintaxis: NOT destino 


Ejemplo: NOT EAX — realiza la inversión del valor de registro EAX y guarda el 
resultado en este registro. 


CMP 


Descripción: esta instrucción resta la “fuente” del “destino” y define los “flags” 
adecuados según el resultado, permitiendo así la comparación de dos valores. Los “flags” 
definidos pueden utilizarse posteriormente en una instrucción condicionada, como una 
bifurcación. Esta instrucción no altera los valores de “fuente? ni de “destino”. 

Esta instrucción goza de gran popularidad entre los crackers. 


Sintaxis: CMP destino, fuente 


Ejemplo: CMP EAX, EDX — comparación entre los valores de los registros EAX y 
EDX. 


CMP EAX, 34h — comparación del valor de registro EAX y el valor 3Ah. 


JNZ 00402000 — si los valores no fueran iguales, el control pasaría a la 
instrucción en la dirección 00402000. 


Operación: Por ejemplo: if (variable_destino == varaible2_fuente)... 
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TEST 


Descripción: al igual que sucedía con AND, TEST realiza una conjunción lógica 
entre “fuente” y “destino”. Sin embargo, esta instrucción no guarda el resultado en 
ninguna parte (esto es, los valores de “fuente” y “destino” no varian), sólo se utilizan para 
definir los “flags” apropiados. A esta instrucción le suele seguir frecuentemente la 
instrucción de una bifurcación condicionada. 


Sintaxis: TEST destino, fuente 


Ejemplo: TEST EAX, EDX -— realiza una conjunción lógica entre los valores de 
los registros EAX y EDX, también define los “flags” correspondientes según el resultado. 


PUSH 


Descripción: esta instrucción guarda un valor en la pila, 
Sintaxis: PUSH valor 
Ejemplo: PUSH EAX — guarda el valor de EAX en la pila. 


POP 


Descripción: esta instrucción guarda un valor de la pila en “destino”. 
Sintaxis: POP destino 
Ejemplo: POP EAX — guarda el valor de la pila en el registro EAX. 


ADD 


Descripción: esta instrucción añade “fuente? a “destino? y guarda el resultado en 
destino”. 


Sintaxis: ADD destino, fuente 


Ejemplo: ADD EAX, EDX — añade el valor del registro EAX a EDX y almacena el 
valor en el registro EAX. 
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ADD EAX, 3Ah — añade el valor del registro EAX al valor 3Ah y almacena el 
valor en el registro EAX. 


Operación: variable_destino = variable_destino + variable2_fuente 


SUB 


Descripción: esta instrucción resta “fuente” a “destino” y guarda el resultado en 
“destino”. 


Sintaxis: SUB destino, fuente 


Ejemplo: SUB EAX, EDX — resta el valor del registro EAX a EDX y almacena el 
valor en el registro EAX, 


SUB EAX, 3Ah — resta el valor del registro EAX al valor 3Ah y almacena el 
valor en el registro EAX. 


Operación: variable_destino = variable_destino — variable2_fuente 


CALL 


Descripción: esta instrucción desplaza el control a un subprograma (llama a una 
función) en la dirección indicada y al mismo tiempo guarda el valor de la dirección 
siguiente (esto es, la dirección de la instrucción que sigue inmediatamente a la instrucción 
CALL) en la pila. La instrucción RET se encarga de devolver el control desde el 
subprograma. 


Sintaxis: CALL dirección del subprograma (función) 
Ejemplo: CALL 00402000 — invocación a la función con dirección 00402000. 


CALL EAX — invocación a la función en la dirección indicada por el valor de 
registro EAX. 


JMP 


Descripción: instrucción de bifurcación no condicionada que desplaza el control a 
la instrucción de la dirección indicada. 


Sintaxis: JMP dirección 
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Ejemplo: JMP 00402000 — desplazamiento del control a la instrucción indicada en 
la dirección 00402000. 


JMP EAX — desplazamiento del control a la instrucción indicada por la dirección 
definida en el valor del registro EAX, 


Bifurcaciones condicionadas 


Estas bifurcaciones condicionadas comprueban el valor de uno o más atributos 
(“flags”) del registro EFLAGS y según el resultado saltarán o no a una dirección 
especifica. De estas instrucciones aparecerá detrás de aquellas que definan los atributos 
(es decir, CMP). A continuación se enumera una lista de las bifurcaciones condicionadas 
básicas: 


Instrucciones Bifurcación Si ... 


JE/IZ igual/cero 

JNE/JNZ no igual/no cero 

JB/JNAE por debajo/no por encima ni igual 
JAE/JNB por encima O igual/no por debajo 
JBE/JNA por debajo O igual/no por encima 
JA/IJNBE por encima/no por debajo ni igual 
JL/IJNGE inferior/no mayor ni igual 
JGE/JNL mayor O igual/no inferior 
JLE/JNG inferior o igual/no mayor 

JG/INLE mayor /no inferior ni igual 

JS signo 

JNS no signo 

JP/JPE paridad/paridad par 

awp/apo no paridad/paridad 198... 


MENSAJES DE WINDOWS 


De vez en cuando fracasan todas las posibles soluciones para encontrar un 
punto de entrada apropiado al programa (o el cracker es demasiado perezoso para 
encontrarlas). Situación propicia para utilizar los puntos de corte de los mensajes de 
Windows. Ya se mencionó en el capítulo 2 cómo definir este tipo de puntos de corte, 
ahora se examinará su aplicación a los mensajes comunes. 
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WM_ACTIVATE 


El mensaje WM_ACTIVATE se envía tanto a la ventana que está siendo activada 
como a la que está siendo desactivada. Si la ventana utiliza la misma cola de entrada, el 
mensaje se enviará de forma síncrona, primero al procedimiento de ventana 
correspondiente a la ventana de orden superior que se va a desactivar y luego al 
procedimiento de venta de orden superior que se va a activar. Si las ventanas utilizaran 
diferentes colas de entrada, el mensaje se enviará asíncronamente, de manera que la 
ventana quedará activa inmediatamente. 


La ventana recibe este mensaje mediante la función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 
UINT uMsg, A WM_ACTIVATE 
WPARAM  wParam, // activación y opciones de 


// minimización 
LPARAM l1Param // manejador de ventana (HWND) 
Y 


Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


WM_CLEAR 


Una aplicación envía un mensaje WM_CLEAR a un control de edición o de 
combo para borrar (“clear”) la selección actual, si hubiera, desde el control de edición. 


Para enviar este mensaje, invóquese la función SendMessage con los parámetros 
siguientes: 


SendMessage ( 
(HWND) hWnd, // manejador de la ventana de 
// destino 
WM_CLEAR, // mensaje por enviar 
(WPARAM) wParam, // sin usar; debe ser cero 
(LPARAM) lParam // sin usar; debe ser cero 
Y; 


Valores obtenidos 


Este mensaje no devuelve ningún valor. 
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WM_CLOSE 


El mensaje WM_CLOSE se envía para indicar que una ventana o aplicación 
debería finalizar. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 
UINT uMsg, // WM_CLOSE 
WPARAM wParam, // sin usar 


LPARAM lParam // sin usar 
de 


Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


El mensaje WM_COMMAND se envía cuando el usuario selecciona un mandato 
desde un menú, cuando un control envía un mensaje de notificación a su ventana maestra 


o cuando se pulsa una tecla aceleradora. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

WM_COMMAND, // mensaje por enviar 

WPARAM wParam, // código de notificación e 
//identificador 


LPARAM l1Param // manejador de control (HWND) 
d; 


Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


WM_CREATE 


El mensaje WM_CREATE se envía cuando una aplicación solicita crear una 
ventana invocando a la función Create WindowEx o CreateWindow (este mensaje se 
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envía antes de que la función finalice). El procedimiento (de ventana) de la ventana nueva 
recibe este mensaje tras crear la ventana, pero antes de que se haga visible. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 
HWND hwnd, // manejador de ventana 
UINT uMsg, // WM_CREATE 
WPARAM wParam, // sin usar 
LPARAM lParam // fecha de creación 
// (LPCREATESTRUCT) 
db: 


Valores obtenidos 
Cuando una aplicación procesa este mensaje, debería obtener cero para seguir 


creando la ventana. Si la aplicación obtuviese -1, la ventana se suprimiría y la función 
Create WindowEx o Create Window devolvería un manejador nulo (NULL). 


WM_DESTROY 


Se envía el mensaje WM_DESTROY al suprimirse una ventana. Se envía al 
procedimiento de la ventana que se está suprimiendo después de que desaparezca de la 
pantalla. 


Este mensaje se envía en primer lugar a la ventana que está siendo suprimida y 
luego se suprimen sus ventanas dependientes (si existieran). Mientras se procesa el 
mensaje, puede asumirse que aún existen sus ventanas dependientes. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 
LRESULT CALLBACK WindowProc ( 
HWND hwnd, // manejador de ventana 
UINT uMsg, Y WM_DESTROY 
WPARAM wParam, // sin usar 
LPARAM lParam // sin usar 
La 


Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


ORA-MA CAPÍTULO 11: SECCIÓN DE REFERENCIA 347 


WM_GETTEXT 


Una aplicación envía un mensaje WM_GETTEXT para copiar el texto 
correspondiente a una ventana en un buffer del procedimiento que lo invoca. 


Para enviar este mensaje, invóquese la función SendMessage con los parámetros 


siguientes: 


SendMessage ( 


(EWND) hWnd, // manejador a la ventana 
// de destino 

WM_GETTEXT, // mensaje por enviar 

(WPARAM) wParam, // número de caracteres 
// por copiar 

(LPARAM) 1Param // buffer de texto 


Y 

Valores obtenidos 

El valor de retorno será el número de TCHARs copiados descartando el carácter 
nulo de terminación. 
WM_GETTEXTLENGTH 


Una aplicación envía un mensaje WM_GETTEXTLENGTH para conocer la 
longitud, en caracteres, del texto asociado a una ventana. 


Para enviar este mensaje, invóquese la función SendMessage con los parámetros 
siguientes: 


SendMessage ( 
(EWND) hWna, // manejador a la ventana 
// de destino 
WM_GETTEXTLENCTH, // mensaje por enviar 
(WPARAM) wParam, // sin usar; debe ser cero 
(LPARAM) 1Param // sin usar; debe ser cero 


); 
Valores obtenidos 


El valor de retorno será la longitud del texto en TCHARs descartando el carácter 
nulo de terminación. 
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WML_INITDIALOG 

El mensaje WM_INITDIALOG se envía a un procedimiento de cuadro de diálogo 
inmediatamente antes de que se muestre. Los procedimientos de cuadro de diálogo 
normalmente utilizan este mensaje para iniciar los controles y ejecutar cualquier otra 


tarea de inicialización que afecte el aspecto del cuadro de diálogo. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

UINT uMsg, // WM_INITDIALOG 

WPARAM wParam, // manejador de control (HWND) 
LPARAM lParam // parámetro de inicialización 


17 
Valores obtenidos 


El procedimiento del cuadro de diálogo devolverá “TRUE” para que el sistema 
defina el foco del teclado en el control definido por wParam. En caso contrario, devolverá 
“FALSE? para evitar que el sistema defina por omisión el foco del teclado. 


El procedimiento del cuadro de diálogo devolverá el valor directamente. Quedará 
ignorado el valor DWL_MSGRESULT definido por la función SetWindowLong. 


WM_LBUTTONDLCLK 


Se envía el mensaje WM_LBUTTONDLCLK al pulsar el usuario dos veces el 
botón izquierdo del ratón mientras su cursor esté en el área cliente de una ventana. Si no 
se poseyera el ratón, el mensaje se enviaría a la ventana ubicada tras el cursor. En caso 
contrario, el mensaje se enviaría a la ventana que posea el ratón, 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 
HWND hwnd, // manejador de ventana 
UINT uMsg, // WM_LBUTTONDBLCLK 


WPARAM wParam, // indicador clave 
LPARAM lParam // posición horizontal y vertical 


di 
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Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


WM_LBUTTONDOWN 

Se envía el mensaje WM_LBUTTONDOWN al pulsar el usuario el botón 
izquierdo del ratón mientras su cursor esté en el área cliente de una ventana. Si no se 
poseyera el ratón, el mensaje se enviaría a la ventana ubicada tras el cursor. En caso 


contrario, el mensaje se enviaría a la ventana que posea el ratón. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

UINT uMsg, EY WM_LBUTTONDOWN 

WPARAM wParam, // indicador clave 

LPARAM l1Param // posición horizontal y vertical 


Ye 
Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


WM_LBUTTONUP 


Se envía el mensaje WM_LBUTTONUP al liberar el usuario el botón izquierdo 
del ratón mientras su cursor esté en el área cliente de una ventana. Si no se poseyera el 
ratón, el mensaje se enviaría a la ventana ubicada tras el cursor. En caso contrario, el 
mensaje se enviaría a la ventana que posea el ratón, 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

UINT uMsg, // WM_LBUTTONUP 

WPARAM wParam, // indicador clave 

LPARAM 1lParam // posición horizontal y vertical 


do 
Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 
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WM_QUIT 
El mensaje WM_QUIT solicita finalizar una aplicación; se genera cuando la 
aplicación invoca la función PostQuitMessage. Provoca que la función GetMessage 


devuelva el valor cero. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

UINT uMsg, // WM_QUIT 

WPARAM wParam, // indicador clave 

LPARAM l1Param // posición horizontal y vertical 


Xi 
Valores obtenidos 


Este mensaje no tiene valor de retorno ya que su proceso concluye antes de que el 
mensaje se envíe al procedimiento de ventana de la aplicación. 


WM_TIMER 


Se envía el mensaje WM_TIMER a la cola de mensajes del hilo de instalación 
cuando concluye un contador. Las funciones GetMessage o PeekMessage son las 
encargadas de enviar este mensaje. 


Este mensaje lo recibe la ventana a través de su función WindowProc. 


LRESULT CALLBACK WindowProc ( 


HWND hwnd, // manejador de ventana 

UINT uMsg, 14 WM_TIMER 

WPARAM wParam, // indicador clave 

LPARAM lParam // posición horizontal y vertical 


); 
Valores obtenidos 


Si una aplicación procesa el mensaje, debería ser cero. 


ACCESO AL REGISTRO DE WINDOWS 


Muchas aplicaciones actuales acceden al registro del sistema operativo con el 
objeto de almacenar ciertos datos necesarios para la operativa del programa. Estos 
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datos pueden variar enormemente: desde aquellos que definen las características del 
programa a los que se encargan de su protección (número de serie, contraseña, etc.). 
Resulta, por tanto, muy útil conocer las funciones API empleadas para acceder al 
registro del sistema operativo. 


RegCreateKey / RegCreateKeyA / RegCreateKeyW 


La función RegCreateKey crea la clave indicada en el registro. Si la clave ya 
existiera, la función la abriría. 


Se incluye esta función sólo para mantener la compatibilidad con las versiones 
Windows de 16 bits. En condiciones normales las aplicaciones deberían utilizar la 
función RegCreateKeyEx. 


LONG RegCreateKey ( 

HKEY hKey, // manejador de la clave abierta 
LPCTSTR lpSubKey, // nombre de la subclave 

PHKEY phkResult // buffer del manejador de clave 


e 
Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error, 


RegCreateKeyExA / RegCreateKeyExW 


La función RegCreateKeyEx crea la clave indicada en el registro. Si la clave ya 
existiera, la función la abriría. 


LONG RegCreateKeyEx ( 


HKEY hKey, ; // manejador de la clave 
// abierta 

LPCTSTR 1pSubKey, // nombre de la subclave 

DWORD Reserved, // reservado 

LPTSTR lpClass, // clase de caracteres 

DWORD dwOptions, // opciones especiales 

REGSAM samDesired, // acceso de seguridad 


// deseado 
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LPSECURITY ATTRIBUTES lpSecurityAttributes, 
// herencia 
PHKEY phkResult, // manejador de clave 
LPDWORD lpdwDisposition // buffer del valor de 
// disposición 


); 
Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 


RegDeleteKey / RegDeleteKeyA / RegDeleteKeyW 

La función RegDeleteKey borra una subclave. 

Windows 95/98/Me: la función también borra todas las subclaves y subvalores. Si 
se desease borrar sólo una clave que no tenga subclaves o valores, utilícese la función 
SHDeleteEmptyKey. 

Windows NT/2000/XP: la subclave que se desea suprimir no debe contener 
subclaves. Si se deseara borrar una clave y todas sus subclaves, deberá primero 


enumerarse sucesivamente todas las subclaves y borrarlas individualmente. Empléese la 
función SHDeleteKey con objeto de borrar las claves de forma sucesiva. 


LONG RegDeleteKey ( 


HKEY hKey, // manejador de la clave 
// abierta 
LPCTSTR lpSubKey, // nombre de la subclave 


Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 
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RegDeleteValue / RegDeleteValueA / RegDeleteV alueW 


La función RegDeleteValue suprime un valor dado de la clave del registro 
indicada. 


LONG RegDeleteValue ( 
HKEY hKey, // manejador de la clave 
LPCTSTR l1lpValueName, // nombre del valor 


Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT _MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 


RegOpenKey / RegOpenKeyA / RegOpenKeyW 
La función RegOpenKey abre la clave del registro indicada. 


Se incluye esta función sólo para mantener la compatibilidad con las versiones 
Windows de 16 bits. En condiciones normales las aplicaciones deberían utilizar la 
función RegOpenKeyEx. 


LONG RegOpenKey ( 
HKEY hKey, // manejador de la clave abierta 
LPCTSTR IpSubKey, // nombre de la subclave 
PHKEY phkResult // manejador de la clave abierta 
) 


Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT _MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 
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RegOpenKeyExA / RegOpenKeyExW 


La función RegOpenKeyEx abre la clave indicada del registro. 


LONG RegOpenKeyEx ( 


BKEY hKey, // manejador de la clave 
// abierta 

LPCTSTR 1pSubKey, // nombre de la subclave 

DWORD ulOptions, // reservado 

REGSAM samDesired, // acceso de seguridad 
// deseado 

PHKEY phkResult, // manejador de la clave 
// abierta 


Yi 

Valores obtenidos 

Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 

Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 


RegQueryValue / RegQueryValueA / RegQuery Value W 


La función RegQueryValue obtiene el dato asociado al valor por omisión o dado 
de una clave de registro indicada. El dato no debe ser un carácter de terminación nulo. 


Se incluye esta función sólo para mantener la compatibilidad con las versiones 


Windows de 16 bits. En condiciones normales las aplicaciones deberían utilizar la 
función RegQueryValueEx. 


LONG RegQueryValue ( 


HKEY hKey, // manejador de la clave abierta 
LPCTSTR lpSubKey, // nombre de la subclave 
LPTSTR lpValue, // buffer para caracteres 


PLONG lpcbValue // tamaño de los caracteres 
// obtenidos 
); 
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Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 


RegQueryValueEx / RegQuery ValueExA / 
RegQueryValueExW 


La función RegQueryValueEx obtiene el tipo y dato de un valor asociado a una 
clave de registro abierta. 


LONG RegQueryValueEx ( 


HKEY hKey, // manejador de clave 
LPCTSTR lpValueName, // nombre del valor 

LPDWORD lpReserved, // reservado 

LPDWORD l1pType, // buffer para el tipo 
LPBYTE l]pData, // buffer de datos 

LPDWORD ]pcbData // tamaño del buffer de datos 


e 
Valores obtenidos 
Si la función finaliza con éxito, el valor de retorno será ERROR_SUCCESS. 


Si la función no finaliza con éxito, el valor de retorno será uno de los códigos de 
error definido en Winerror.h. Se puede emplear la función FormatMessage con el atributo 
FORMAT_MESSAGE_FROM_SYSTEM si se deseara obtener una descripción general 
del error. 


RESUMEN DE FUNCIONES DE SOFTICE 


La sección siguiente enumera de forma ordenada las funciones de SoftICE versión 
4 para Windows NT. Ojalá sean de utilidad. 
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Definición de puntos de corte 


BPM, BPMB, BPMW, BPMD - - puntos de corte para acceder a memoria 
BPIO  - punto de corte para acceder al puerto de 1/0 

BPINT - punto de corte a una interrupción 

BPX  - punto de corte para ejecución 

BPTE  - punto de corte para ejecución de hilo en anillo 3 

BMSG  - punto de corte a un mensaje Windows 

BSTAT - estadísticas de puntos de corte 

CSIP - definición del indicador de ámbito CS:ElP 


Manejo de los puntos de corte 


BPE  - edición de punto de corte 

BPT  - empleo de punto de corte como plantilla 
BL - enumerar los puntos de corte actuales 
BC  - borrar punto de corte 

BD - - inhabilitar punto de corte 

BE - - habilitar punto de corte 

BH  - histórico de puntos de corte 


Modificar y mostrar memoria 


R  - muestra o modifica el contenido de un registro 
U  -desensambla instrucciones 

D, DB, DW, DD, DS, DL, DT - muestra memoria 

E, EB, EW, ED, ES, EL, ET - edita memoria 

PEEK  - lee una dirección física 

POKE  - escribe en una dirección física 

PAGEIN - - carga una página en memoria física (nota: no siempre es seguro) 
H  - ayuda sobre la función indicada 

?  - calcula expresión 

VER  - versión de SoftICE 

WATCH - añade reloj 

FORMAT - cambia el formato de la ventana de datos 
DATA - abre y cambia a la ventana de datos N 


Obtención de información sobre el sistema 


GDT  - muestra la tabla de descripción general 
LDT - muestra la tabla de descripción local 
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IDT - muestra la tabla de descripción de interrupciones 

IRQ- - muestra información hardware sobre IRQs 

TSS - muestra el estado de los segmento de la tarea 

CPU - muestra información de los registros de la CPU 

PCI - muestra información de los dispositivos PCI 

USB - muestra información de los dispositivos USB o información de una 
transacción 

MOD - muestra la ventana con la lista de módulos 

HEAP - muestra la ventana de memoria global 

LHEAP - muestra la ventana de la memoria local 

TASK - muestra la ventana de lista de tareas 

NTCALL- - muestra las llamadas al sistema NTOSKRNL 

WMSG - muestra la ventana de mensajes 

PAGE - muestra información sobre la tabla de páginas 

PHYS - muestra todas las direcciones virtuales de direcciones físicas 

STACK - muestra llamadas a la pila 

XFRAME - muestra los marcos de la excepción activos 

MAPV86 - muestra mapa de memoria v86 

HWND - muestra ventana de información sobre manejadores 

CLASS - muestra ventana de información sobre clases 

THREAD - muestra información sobre un hilo 

ADDR - muestra y modifica el contexto de dirección 

MAP32 - muestra un mapa de sección de 32 bits 

PROC - muestra información de un proceso 

QUERY - muestra los procesos de un mapa de direcciones virtuales 

WHAT - identifica el tipo de una expresión 

OBJTAB - muestra información sobre una tabla de objetos de usuario 

OBJDIR - muestra información sobre un directorio objeto 

DEVICE - muestra información sobre un dispositivo 

DRIVER - muestra información sobre un driver 

FOBJ - muestra información sobre un archivo objeto 

IRP - muestra información sobre un IRP 

FIBER - muestra información sobre una fibra 

INTOBJ - muestra información sobre objetos interruptores 

TIMER - muestra información sobre timer objetos contador 

EVENT - muestra alertas de boundschecker 

EVMEM.  - muestra alertas de memorias de boundschecker 

EVRES - muestra alertas sobre recursos de boundschecker 

DPC  - muestra información sobre llamadas de procedimiento diferidas (en 

inglés, “Delayed Procedure Calls”) 

APC  - muestra información sobre llamadas de procedimiento asíncronas (en 
inglés, “Asynchronous Procedure Calls”) 

ERESOURCE  - muestra información sobre ERESOURCE, objetos de 

sincronización 
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KMUTEX - muestra información sobre un mutex del kernel 
KEVENT - muestra información sobre alertas del kernel 

KSEM - - muestra información sobre semáforos del kernel 
FMUTEX - muestra información sobre un objeto mutante del kernel 
PACKET - muestra el contenido de un buffer de un paquete (de red) 
l — - ejecuta una extensión del depurador del kernel 


Mandatos para los puertos de entrada y salida (1/0) 


I, IB, TW, ID 
- lee datos de un puerto 1/O 
O, OB, OW, OD 


- escribe datos a un puerto 1/O 


Mandatos para controlar el flujo 


X - volver al depurador o programa 

G - ir a dirección 

T - paso a una instrucción 

P - paso saltando llamadas, interrupciones, etc. 

HERE - ira la actual posición del cursor 

EXIT - forzar y salir al actual DOS/Windows programa 
GENINT - generar una interrupción 

HBOOT - reinicio del sistema (reinicio total) 


Modo de control 


TIHERE - dirige INTI a SoftICE 

BHERE  - dirige INT3 a SoftICE 

ZAP- suprime INT] o INT3 ya incluidas en el código 

FAULTS - habilita o deshabilita la captura de errores de SoftICE 
SET - cambia una variable interna 


Mandatos de personalización 


PAUSE - controla la visualización en pantalla de cada página 
ALTKEY - selecciona la secuencia de teclas para invocar una ventana 
FKEY  - muestra o selecciona las teclas de función 

DEX  - muestra o asigna las expresiones a la ventana de datos 
CODE - muestra los bytes de instrucciones en la ventana de código 
COLOR - muestra o selecciona los colores de la pantalla 
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ANSWER - responde automáticamente y envía los datos de consola al módem 
DIAL - asigna la consola al módem 

NET - interfaz para depurado remoto 

SERIAL - asigna la consola a un terminal serie 

TABS - selecciona o muestra las opciones de tabulación 

LINES - selecciona o muestra el número de líneas en pantalla 

WIDTH - selecciona o muestra el número de columnas en pantalla 

PRN  - selecciona el puerto de la impresora 

Tecla PRINT-SCREEN - volcado de pantalla a la impresora 

MACRO - define un nombre de macro para SoftICE 


Utilidades 


A - ensamblar código 

S - buscar datos 

F - rellenar la memoria con datos 

M - mover datos 

C - comparar dos bloques de datos 

HS - buscar en el buffer histórico una secuencia dada 


Uso de las teclas del editor de líneas 


Flecha hacia arriba - obtiene el mandato anterior 

Flecha hacia abajo - obtiene el mandato siguiente 

Flecha hacia la derecha - desplaza el cursor hacia la derecha 
Flecha hacia la izquierda - desplaza el cursor hacia la izquierda 
Tecla de retroceso - suprime el último carácter 

Inicio - comienzo de línea 

Fin - inicio de línea 

Insert - modo de inserción 

Supr - suprime carácter 

ESC - cancela el mandato actual 


Uso de las teclas de desplazamiento 


RePág - muestra la página anterior del histórico 

AvPág - muestra la página siguiente del histórico 

Alt+flecha hacia arriba - una línea hacia arriba en la ventana de datos 
Alt+flecha hacia abajo - una línea hacia abajo en la ventana de datos 
Alt+RePág - una página hacia arriba en la ventana de datos 
Alt+AvPág - una página hacia abajo en la ventana de datos 
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Ctrl+RePág - una página hacia arriba en la ventana de código 
Ctrl+AvPág - una página hacia abajo en la ventana de código 
Ctri+flecha hacia arriba - una línea hacia arriba en la ventana de código 
Ctri+flecha hacia abajo - una línea hacia abajo en la ventana de código 


Mandatos de ventana 


WC - cambia ventana de código 
WD - cambia ventana de datos 
WF - cambia la ventana de la pila de punto flotante 
WL - cambia ventana de variables locales 
WR - cambia ventana de registros 
WT - cambia ventana de hilos 
WS - cambia ventana de la pila de invocaciones 
WW - cambia ventana de reloj 
WX - cambia ventana registros XMM 
EC - activa o desactiva ventana de código 
- localiza la instrucción actual 


Control de ventana 


CLS  - despeja la ventana 

RS  - restaura la pantalla del programa 

ALTSCR - envía información a pantalla alternativa 
FLASH - restaura la pantalla durante los mandatos P y T 


Mandatos sobre símbolos y fuente 


SYM - - muestra símbolos 

SYMLOC - reubica la base de simbolos 

EXP  - muestra los símbolos exportados 

SRC  - alterna en pantalla el código, el fuente y modo mixto 
TABLE - selecciona o suprime la tabla de símbolos 

FILE - modifica o muestra el fichero fuente actual 

SS  - busca una secuencia de caracteres en el módulo fuente 
TYPES - enumera todos los tipos o muestra una definición de tipo 
LOCALS - muestra las variables locales controladas actualmente 
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Operadores especiales 


- ante un número decimal indica un número de línea 
$ - ante una dirección indica la dirección de segmento 
HH - ante una dirección indica la dirección del selector 
(4) - ante una dirección indica su dirección 


BIFURCACIONES CONDICIONADAS, NO 
CONDICIONADAS E INSTRUCCIONES SET 


La enumeración siguiente bien servirá de ayuda para buscar con rapidez un 
formato hexadecimal de una instrucción de bifurcación concreta o una instrucción SET 
sin necesidad de tratar de recordarla ni invertir mucho tiempo localizándola. 


Bifurcaciones condicionadas 


Hexadecimal Instrucción Atributos de instrucción 

77 cb JA rel8 Bifurcación corta si superior (CF=0 y ZF=0) 

73 cb AE rel8 Bifurcación corta si superior o igual (CF=0) 

72 cb JB rel8 Bifurcación corta si inferior (CF=1) 

76 cb JBE rel8 Bifurcación corta si inferior o igual (CF=1 0 ZF=1) 
72 cb JC rel8 Bifurcación corta si acarreo (CF=1) 

E3 cb CXZ rel8 Bifurcación corta si el registro CX es O 

E3 cb IECXZ rel8 Bifurcación corta si el registro ECX es 0 

74 cb JE rel8 Bifurcación corta si igual (ZF=1) 

TF cb JG rel8 Bifurcación corta si mayor (ZF=0 y SF=0F) 

7D cb JGE rel8 Bifurcación corta si mayor o igual (SF=0F) 

TC: Cb JL rel8 Bifurcación corta si menor (SF<>0F) 

TE cb JLE rel8 Bifurcación corta si menor o igual (ZF=1 o SF<>0F) 
76 cb JNA rel8 Bifurcación corta si no superior (CF=1 o ZF=1) 

72 cb JNAE rel8 Bifurcación corta si no superior o igual (CF=1) 

73 cb INC rel8 Bifurcación corta si no acarreo (CF=0) 

75 cb JNE rel8 Bifurcación corta si no igual (ZF=0) 

7E cb ING rel8 Bifurcación corta si no mayor (ZF=1 0 SF<>0F) 
7C cb JNGE rel8 Bifurcación corta si no mayor o igual (SF<>0F) 

7D cb JNL rel8 Bifurcación corta si no menor (SF=0F) 

7F cb JNLE rel8 Bifurcación corta si no menor o igual (ZF=0 y SF=0F) 
71cb JNO rel8 Bifurcación corta si no hay desbordamiento (OF=1) 
7B cb JNP rel8 Bifurcación corta si par (PF=1) 
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79 cb INS rel8 Bifurcación corta si positivo (SF=0) 

75 cb JNZ rel8 Bifurcación corta si distinto de cero (ZF=0) 
70 cb JO rel8 Bifurcación corta si desbordamiento (OF=1) 
7A cb JP rel8 Bifurcación corta si par (PF=1) 

7A cb JPE rel8 Bifurcación corta si par (PF=1) 

7B cb JPO rel8 Bifurcación corta si impar (PE=0) 

78 cb JS rel8 Bifurcación corta si negativo (SF=1) 

74 cb JZ rel8 Bifurcación corta si cero (ZF=0) 


0F 87 cw/cd JA rel16/32 Bifurcación si superior (CF=0 y ZF=0) 

OF 83 cw/cd JAE rel16/32  Bifurcación si superior o igual (CF=0) 

OF 82 cw/cd JB rel16/32 Bifurcación si inferior (CF=1) 

OF 86 cw/cd JBE rel16/32 Bifurcación si inferior o igual (CF=1 0 ZF=1) 
OF 82 cw/cd JC rel 16/32 Bifurcación si acarreo (CF=1) 

OF 84 cw/cd JE rel16/32 Bifurcación si igual (ZF=1) 

OF 84 cw/cd JZ rel16/32 Bifurcación si 0 (ZF=1) 

OF 8F cw/cd JG rel16/32 Bifurcación si mayor (ZF=0 y SF=0F) 

OF 8D cw/cd JGE rell16/32  Bifurcación si mayor o igual (SF=0F) 

OF 8C cw/cd JL rel16/32 Bifurcación si menor (SF<>0F) 

OF 8E cw/cd JLE rel16/32 Bifurcación si menor o igual (ZF=1 o SF<>0F) 
OF 86 ew/cd JNA rel16/32 Bifurcación si no superior (CF=1 0 ZF=1) 

OF 82 cw/cd JNAE rel16/32  Bifurcación si no superior o igual (CF=1) 

OF 83 cw/cd JNB rel 16/32 Bifurcación si no inferior (CF=0) 

0F 87 cw/cd JNBE rel16/32  Bifurcación si no inferior o igual (CF=0 y ZF=0) 
OF 83 cw/cd JNC rel16/32 Bifurcación si no acarreo (CF=0) 

0F 85 cw/cd JNE rel16/32 Bifurcación si no igual (ZF=0) 

OF 8E cw/cd JNG rel 16/32 Bifurcación si no mayor (ZF=1 o SF<>0F) 
OF 8C ew/cd JNGE rel16/32  Bifurcación si no mayor o igual (SF<>0F) 
OF 8D cw/cd JNL rel 16/32 Bifurcación si no menor (SF=0F) 

OF 8F cw/cd JNLE rel16/32  Bifurcación si no menor o igual (ZF=0 y SF=0F) 
0F 81 cw/cd JNO rel16/32  Bifurcación si no hay desbordamiento (OF=0) 
0F 8B cw/cd JNP rel16/32 Bifurcación si impar (PF=0) 

OF 89 cw/cd JNS rel 16/32 Bifurcación si positivo (SF=0) 

0F 85 cw/c JNZ rel16/32 Bifurcación si distinto de cero (ZF=0) 

0F 80 cw/cd JO rel16/32 Bifurcación si desbordamiento (OF=1) 

OF 8A cw/ed JP rel16/32 Bifurcación si par (PF=1) 

OF 8A cw/cd JPE rel16/32 Bifurcación si par (PF=1) 

OF 8B cw/cd JPO rel16/32  Bifurcación si impar (PF=0) 

OF 88 cw/cd JS rel16/32 Bifurcación si negativo (SF=1) 

OF 84 cw/cd JZ rel16/32 Bifurcación si 0 (ZF=1) 
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Bifurcaciones no condicionadas 


Hexadecimal Instrucción Atributos de instrucción 

EB cb JMP rel8 Bifurcación corta, relativa, desplazamiento relativo a 
la instrucción siguiente 

E9 cw JMP rel16 Bifurcación relativa, desplazamiento relativo a la 
instrucción siguiente 

FF /4 JMP 1/m16 Bifurcación absoluta indirecta, address given in r/m16 

FF /4 JMP r/m32 Bifurcación absoluta indirecta, dirección dada en 
1/m32 

EA cb JMP ptr16:16 — Bifurcación larga, absoluta, dirección dada en 
operador 

EA cb JMP ptri6:32 — Bifurcación larga, absoluta, dirección dada en 
operador 

FF /5 JMP m16:16 Bifurcación larga, absoluta indirecta, dirección dada en 
ml6:16 

FF /5 JMP m16:32 Bifurcación larga, absoluta indirecta, dirección dada en 


Instrucciones SET 


m16:32 


Hexadecimal Instrucción Atributos de instrucción 

0F 97 SETA r/m8 Definir byte si superior (CF=0 y ZF=0) 

OF 93 SETAE r/m8 Definir byte si superior o igual (CF=0) 

0F 92 SETB r/m8 Definir byte si inferior (CF=1) 

0F 96 SETBE r/m8 Definir byte si inferior o igual (CF=1 0 ZF=1) 
OF 92 SETC r/m8 Definir byte si acarreo (CF=1) 

OF 94 SETE r/m8 Definir byte si igual (ZF=1) 

0F 9F SETG 1/m8 Definir byte si mayor (ZF=0 y SF=0F) 

0F 9D SETGE r/m8 Definir byte si mayor o igual (SF=0F) 

0F9C SETL r/m8 Definir byte si menor (SF<>0F) 

OF 9E SETLE r/m8 Definir byte si menor o igual (ZF=1 o SF=0F) 
0F 96 SETNA r/m8 Definir byte si no superior (CF=1 0 ZF=1) 

OF 92 SETNAE r/m8 — Definir byte si no superior o igual (CF=1) 

0F 93 SETNB r/m8 Definir byte si no inferior (CF=0) 

0F 97 SETNBE 1/m8 — Definir byte si no inferior o igual (CF=0 y ZF=0) 
0F 93 SETNC r/m8 Definir byte si no acarreo (CF=0) 

0F 95 SETNE 1/m8 Definir byte si no igual (ZF=0) 
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OF 9E 
0F 9C 
0F 9D 
OF 9F 
0F 91 

OF 9B 
OF 99 
OF 95 

0F 90 
OF 9A 
OF 9A 
0F 9B 
OF 98 
OF 94 


SETNG r/m8 
SETNGE 1/m8 


SETNLE t/m8 
SETNO 1/m8 
ETNP 1/m8 
ETNS r/m8 
ETNZ r/m8 
ETO 1/m8 
SETP r/m8 
SETPE r/m8 
SETPO r/m8 
Ss 
S 


ETS 1/m8 
ETZ r/m8 


Definir byte si no mayor (ZF=1 0 SF<>0F) 
Definir byte si no mayor o ¡gual (SF<>0F) 
Definir byte si no menor (SF=0F) 

Definir byte si no menor o igual (ZF=0 y SF=0F) 
Definir byte si no hay desbordamiento (OF=1) 
Definir byte si impar (PF=1) 

Definir byte si positivo (SF=0) 

Definir byte si distinto de cero (ZF=0) 

Definir byte si desbordamiento (OF=1) 
Definir byte si parity (PF=1) 

Definir byte si par (PF=1) 

Definir byte si impar (PF=0) 

Definir byte si negativo (SF=1) 

Definir byte si cero (ZF=0) 


ALGORITMOS CRC-32 


El siguiente listado comprende el código integro en ensamblador del algoritmo 
CRC-32 destinado a realizar el cálculo necesario en la comprobación de integridad (en 
inglés, “checksum”). Ojalá que la tabla de constantes generada para el algoritmo CRC-32 


sea de utilidad. 


/*k**xxxx* tabla de constantes para realizar los cálculos 
precisos de comprobación de integridad ***x*x*x*x*/ 
CRC32 Table[256] = 


const DWORD 


OXEE0E612C, 
0x9F6495A3, 
0x97D2D988, 
0x1DB71064, 
Ox6DDDE4EB, 
OXxFD62F97A, 
0Ox8DO80DF5, 
0x3C03E4D1, 
0x42B2986C, 
OXDCD6ODCF, 
OxBFDO6116, 
0x2802B89E, 
0x58684C11, 
0x98D220BC, 
OxE8B8D433, 
Ox7FG6AODBB, 
0x1C6C6162, 
0x8208F4C1, 
OxFCB9887C, 
0x4DB26158, 
0x3DD895D7, 
0xAD678846, 
OXDDOD7CC9, 
0x5768B525, 


0x990951BA, 
Ox0EDB8832, 
0x09B64C2B, 
Ox6AB020F2, 
OXF4D4B551, 
OXBAG5C9EC, 
0x3B6E20C8, 
0x4B04D447, 
OXDBBBC9D6, 
OxABD13D59, 
0x21B4F4B5, 
0x5F058808, 
OXC1611DAB, 
OXEFD5102A, 
0x7807C9A2, 
0x086D3D2D, 
0x856530D8, 
OXF50FC457, 
0x62DD1DDF, 
0x3AB551CE, 
OxA4D1C46D, 
OXxDAGOB8DO, 
0x5005713C, 
0x206F85B3, 


0x076DC419, 
Ox79DCB8A4, 
0x7EB17CBD, 
0xF3B97148, 
0x83D385C7, 
0x14015C4F, 
0x4C69105E, 
OxD20D85FD, 
OXACBCF940, 
0x26D930AC, 
0x56B3C423, 
OXC60CD9B2, 
0xB6662D3D, 
0x71B18589, 
Ox0F00F934, 
0x91646C97, 
0xF262004E, 
Ox65BOD9C6, 
0x15DA2D49, 
OXA3BC0074, 
OxD3D6F4FB, 
0x44042D73, 
0x270241AA, 
OXB966D409, 


0x00000000, 0x77073096, 


0x706AF48F, 0xE963A535, 
OxEOD5E91E, 
0xE7B82D07, Ox90BF1D91, 
0x84BE41DE, Oxl1ADAD47D, 
0x136C9856, 0x646BA8C0, 
0x63066CD9, OxXFAOF3D63, 
0xD56041E4, 0xA2677172, 
OxA50AB56B, 0x35B5A8FA, 
0x32D86CE3, 0x45DF5C75, 
Ox51DE003A, 0xC8D75180, 
OXCFBA9599, OXB8BDA5OF, 
OxB10BE924, 0x2F6F7C87, 
0x76DC4190, 0x01DB7106, 
Ox06B6B51F, OX9FBFE4AS, 
0x9609A88E, 0xEl0E9818, 
0xE6635C01, OX6B6B51F4, 
Ox6C0695ED, Ox1BO1A57B, 
0x12B7E950, Ox8BBEB8EA, 
0x8CD37CF3, 0xFBD44C65, 
OxD4BB30E2, 0x4ADFA541, 
0x4369E96A, 0x346ED9FC, 
0x33031DE5, OXAAOA4C5F, 
OxBE0B1010, 0xC90C2086, 
OxCE61E49F, OX5EDEF9OE, 
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0x29D9C998, OxB0D0O9822, OxC7D7A8B4, 0x59B33D17, 0x2EB40D81, 
OxB7BD5C3B, OXCOBAGCAD, OxEDB88320, OX9ABFB3B6, 0x03B6E20C, 
0x74B1D29A, 0xEAD54739, 0x9DD277AF, 0x04DB2615, 0x73DC1683, 
0xE3630B12, 0x94643B84, Ox0D6D6A3E, OX7AGASARS, OXE40ECFOB, 
0x9309FF9D, OX0A00AE27, 0x7D079EB1, 0xXF00F9344, 0x8708A3D2, 
0x1E01F268, 0x6906C2FE, 0xF762575D, 0x806567CB, 0x196C3671, 
OX6E6B06E7, OXFED41B76, 0x89D32BE0, Oxl10DA7ASA, 0x6'7DD4ACC, 
OXF9BIDF6F, OXBEBEEFF9, 0x17B7BE43, Ox60B08ED5, OxD6D6A3E8, 
0xA1D1937E, 0x38D8C2C4, Ox4FDFF252, OXD1BB67F1, OXA6BC5767, 
Ox3FB506DD, 0x48B2364B, OxD80D2BDA, OXAFOA1B4C, 0x36034AF6, 
0x41047A60, OXDF60EFC3, OxA867DF55, 0x316EBEEF, 0x4669BE79, 
OxCB61B38C, OxBC66831A, 0x256FD2A0, 0x5268E236, OxCC0OC7795, 
OxBB0B4703, 0x220216B9, 0x5505262F, OXC5BA3BBE, OxB2BD0B28, 
Ox2BB45A92, Ox5CB36A04, OxC2D7FFA7, OXB5DOCF31, 0x2CD99E8B, 
Ox5BDEAE1D, 0x9B64C2B0, 0xEC63F226, 0x756AA39C, 0x026D930A, 
Ox9C0906A9, OXEBOE363F, 0x72076785, 0x05005713, 0x95BF4A82, 
OxE2B87A14, 0x7BB12BAE, 0x0CB61B38, 0x92D28E9B, OxXE5D5BE0D, 
Ox7CDCEFB7, OXOBDBDF21, 0x86D3D2D4, 0xF1D4E242, Ox68DDB3F8, 
Ox1FDA836E, 0x81BE16CD, OxF6B9265B, OX6FBO0O77El, 0x18B74777, 
0x88085AE6, OXFFOF6ATO, Ox66063BCA, OX11010B5C, Ox8F659EFF, 
0xF862AE69, OX616BFFD3, O0x166CCF45, OXA00AE278, OxD70DD2EE, 
0x4E048354, 0x3903B3C2, 0xA7672661, 0xD06016F7, 0x4969474D, 
0x3EG6E77DB, OXAEDI16ALA, OXD9DE5ADC, OX40DFOB66, 0x37D83BFO0, 
OxA9BCAE53, OXDEBB9EC5, 0x47B2CF7F, Ox30B5FFE9, OxXBDBDF21C, 
OXCABAC28A, 0x53B39330, 0x24B4A3A6, OXBADO3605, 0xCDD70693, 
0x54DE5729, 0x23D967BF, 0xB3667A2E, 0xC4614AB8, 0x5D681B02, 
0x2A6F2B94, OXB40BBE37, 0xC30C8EA1, OX5AOS5DF1B, 0x2D02EF8D 


7 


RRA 


/** Información de entrada: **/ 
/**  ESI = dirección de la tabla CRC-32 **/ 
/** EDI = dirección de los datos por comprobar **/ 
/*x*  ECX = longitud de los datos **/ 


/** Salida: EAX = comprobación de integridad CRO-32 **/ 
EOS OESOTO 
CROI2:: 

mov eax, OFFFFFFFFh 

mov edx, eax 


CcRC32_loop: 
push ecx // guardando el valor ECX - Se emplea como 
// contador en el bucle 
xor ebx,ebx 
mov bl1,byte ptr [edi] // leyendo byte de los 
//datos 
inc edi // desplazándose al byte siguiente 


xor bl,al // operaciones matemáticas relacionadas con 
// el cálculo de la comprobación de 
// integridad 


shl bx,1 
shl bx,1 
add ebx,esi 


mov cx,word ptr [ebx+2] // cargando valores de la 
// tabla CRC 
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mov 


mov 
mov 
mov 
xor 


xor 
xor 


Pop 


bx,word ptr [ebx] 


al,ah 
ah, dl 
dl,dh 
dh, dh 


ax, bx 
AR, EX 


ecx // Cargando el valor ECX para la siguiente 
// instrucción del bucle 


loop CRC32_loop 


not 
not 


ax 
dx 


push dx  // guardando dos valores de 16 bits que 


// conjuntamente representan la comprobación 
// de integridad 


push ax 


pop 


ret 


eax // valor de la comprobación de integridad de 


// 32 


OTROS ALGORITMOS APLICABLES A 
CODIFICADORES Y COMPRESORES PE 


El siguiente algoritmo resultará de gran utilidad a quienes, sin saber procesar 


reubicaciones, deseen programar un codificador o compresor PE que también sirva 
para las librerías DLL. Aunque su autor, de sobrenombre Stone, afirme que este 
algoritmo contiene ciertos errores, en la mayoría de las ocasiones funciona 
normalmente. 

AE A 


/* Procedimiento para procesar reubicaciones */ 
* 


el (c) Stone 
A 


SA 


/**Información de entrada: *k/ 
/** App dwNewImageBase = NewImageBase **/ 
/** App dwOl1dIB = ImageBase original **/ 
/** App Reloc = puntero RVA a reubicaciones +./ 


RRA RR OOOO ARA AAA AAA AAA 


HandleReloc: ; Procedimiento para manejar 
; reubicaciones 
mov edx, [App dwNewImageBase+ebp] 
mov eax, [App dwOldIB+ebp] 
sub edx, eax E ¿ImageBases idénticas? 
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jz EndReloc 5 bifurcación = sí - no existe 
¡problema de reubicación 

mov eax, edx 

shr eax, 16 ; AX = 16 bits superiores 

xor ebx, ebx ; preparar EBX 

mov esi, [App _Reloc+ebpl] 

add esi, [App _dwNewImageBase+EBP] ; ESI = tabla de 

¡reubicaciones 
NextPage: ; realizar una página 


cmp dword ptr [esil,0 q 
jz EndReloc 


¿final? 


número de bytes en la estructura 


entradas de tamaño 


=> ecx = número de entradas 


; RVA => VA 


entrada para el primer ítem 


mov ecx, [ESI+4] ó 
sub ecx, 8 ; Menos RVA £ 
shr ecx, 1 ; 1 palabra por entrada 
mov edi, [esil ; página actual RVA 
add edi, [App _dwNewImageBase+ebp] 
add esi, 8 ¡ ESI = 

NextlItem: 


mov bx, word ptr [ESI] 
shr ebx, 12 ; EBX = tipo 
cmp ebx, 1 

jz typel 


cmp ebx,2 
jz type2 


cmp ebx, 3 
jz. type3 


jmp NoType 


typel: 
mov bx, word ptr [ESI] 
and ebx, Offfh z 
add word ptr [edi+ebx], ax 
jmp NoType 
type2: 
mov bx, word ptr [ESI] 
and ebx, Offfh 


add word ptr [edi+ebx], dx 
jmp NoType 


¿8fffh máscara correcta ? 
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type3: 

mov bx, word ptr [ESI] 

and ebx, Offfh 

add dword ptr [edi+ebx],edx 


jmp NoType 


NoType: 
add esi, 2 ¡; next offset 
loop NextItem 


jmp NextPage 


EndReloc: 
ret 


EJEMPLO DE ALGORITMO DE CODIFICACIÓN 


El algoritmo de codificación siguiente resultará útil para quien no sepa cómo 
codificar. Emplea principalmente una tabla de valores codificados; su creador, David 
Sehnal, es amigo del autor de este libro. 


AA 
/* Algoritmos de codificación */ 
/* (Cc) David Sehnal */ 


AA 


/*EKX**** tabla de valores para la codificación ***x*x*x*x*/ 
static unsigned long tab[256] = (2441417007, 3143821471, 
3102279737, 3381954670, 2988039964, 2513049361, 2487874078, 
2491016945, 3828261054, 3608022026, 2884606139, 2518469068, 
3075095765, 3817002566, 2690415125, 2458679274, 3859063267, 
3348150702, 3213091002, 3091148279, 3919876699, 3624438408, 
2556754312, 2698396799, 2544385734, 3650266848, 2737802314, 
3185648724, 3743438646, 2475236962, 2772860394, 3398705118, 
2946024257, 2432499648, 3328906258, 2938719201, 3189603690, 
3344320213, 2593349762, 2418710844, 3868973949, 3890000744, 
3027069153, 3639120578, 3448723817, 3915883906, 2731471965, 
3251254645, 3417130610, 4156985833, 2946372266, 3206865958, 
3047690171, 2530286562, 2445912902, 2593008563, 2739528455, 
3193125337, 2447359840, 3298900365, 2453607611, 3457921575, 
2677814715, 3262607727, 3868182955, 3445773453, 3323450099, 
3644750590, 2769586203, 3570428512, 3384492757, 3676902144, 
3172992829, 2460188612, 3245436075, 3434439408, 3096313000, 
3442161849, 2972296556, 3526659930, 3302855331, 2749007489, 
3158107393, 3659035000, 2658149194, 3434993362, 2791730865, 
2781962923, 2447465780, 3057471302, 2947216313, 2780846227, 
3120182388, 2696693952, 2866097403, 3175365810, 3610505228, 
3301747063, 3156570022, 2504556891, 3471895270, 2866111012, 
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2682426827, 3014189275, 2727756612, 3455021348, 2877281020, 
3828493700, 2725383632, 3933613598, 3093869415, 3618787395, 
2895586796, 3554778228, 2699699638, 2524238667, 2803785035, 
3015500086, 2418601965, 2991808815, 2870181950, 3037005546, 
2849608349, 3865298157, 2472358807, 3214357191, 2540204969, 
2637025018, 2529263802, 2985020337, 2435874776, 3240925202, 
3657592599, 3875882655, 3278052448, 3134745973, 2424992262, 
4118845106, 2772679527, 2790803438, 2710075583, 2725586784, 
2807978763, 3718638678, 3528334974, 4112771044, 2922799249, 
3072629728, 3203469339, 2711632860, 3145054814, 2805878841, 
2589146654, 3205820672, 3266929119, 3306717240, 3004464709, 
3831065933, 2909083492, 2529449918, 2934159356, 3760311328, 
3269340681, 2572582322, 2878882877, 3248722150, 3054319801, 
3550668906, 2585238216, 3769066731, 3318657120, 3484178933, 
3091008691, 3709420544, 2845116815, 3874185200, 3913548752, 
4034683788, 2740545466, 3095010188, 3242739834, 3346837392, 
2869443445, 3189464103, 3663827488, 3917963314, 2873060787, 
3052994480, 3827981880, 2750758569, 3236965464, 3591428330, 
2989715009, 3586297681, 3350761036, 3936394503, 3403776781, 
4189435547, 2888223482, 3631024528, 2433041783, 3796536810, 
2463728315, 3592219323, 3575189700, 2987646959, 2978807772, 
2465891273, 3192488489, 3212332504, 2578578946, 2526146357, 
3498091110, 3335072318, 2484286880, 3440115948, 2484037592, 
4014655803, 2842222941, 2622089202, 3720872070, 2940094173, 
2818921225, 3369671008, 2813928362, 2494881899, 2874296713, 
3765214229, 2592775917, 3907292666, 2700031228, 2601849077, 
3146610873, 4079117462, 2632206052, 2942627638, 3536105321, 
3218789614, 3013504118, 3829796513, 2459935558, 3610976975, 
3387266053, 3445048025, 2688020827, 4060074459, 2912941991, 
2712495093, 3491530518, 2617402828, 2897809440, 3676064622, 
2652240008, 3163302244, 2956470681, 3841847530, 


i 


/****x** definición de clases y variables *****x*x*/ 
class Crypto 


unsigned long table[256]; 
public: 
void Init (unsigned char key[], int nbytes); 
void Encode (unsigned char *input,unsigned char 
*output, unsigned long size); 
void Decode (unsigned char *input,unsigned char 
*output, unsigned long size); 


Crypto() ([ ) 
virtual -Crypto() [ ) 


¡E 


union myulong ( 
unsigned long ulong; 
struct 
unsigned int byte3:8; 
unsigned int byte2:8; 
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unsigned int bytel:8; 
) unsigned int byte0:8; 
w; 


de 


[*RXXA AA Funciones*****x**/ 
void Crypto::Init (unsigned char key[],int nbytes) 


myulong t; 

for (int i = 0; i < nbytes / 4; i++) 
t.w.byte0 = OxAF * key[4*1i]; 
t.w.bytel = 0x1B * key[4*i+1]; 
t.w.byte2 = Ox5A * key[4*i+2]; 
t.w.byte3 = 0xF1 * key[4*i+3]; 


for (i = 0; 1 < 256; 1++) 


table[i] = (tab[i] * t.ulong); 


void Crypto::Encode (unsigned char *input, unsigned char 
*output, unsigned long size) 


myulong t; 
for (unsigned long i = 0; i < size; i++) 
t.ulong = tableli % 255]; 


outputlil] = (((input[i] * t.w.byte2) 
t.w.byte3) % t.w.bytel) ” t.w.byte0; 


A 


) 


void Crypto: :Decode (unsigned char *input,unsigned char 
*output, unsigned long size) 


myulong t; 
for (unsigned long i = 0; i < size; i++) 
t.ulong = tableli % 2551; 


output [il] = (((input [i] 
t.w.bytel) * t.w.byte2) 


A 


>» ye 


mot 


.w.byte0) 
.w.byte2; 


) 


[***X**** ejemplo de uso del algoritmo - parte del 
programa para probar este algoritmo de codificación. 
Se incluye en el CD adjunto*+***x**x*/ 
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void CCryptDlg: :OnO0k () 


unsigned char key[64] = ( // clave de cifrado 

68,201, 136,, 13, 
175,102 ,88.,228, 
166,249,51,108, 
37,40,13,194, 
92,33,94,203, 
572124193 1 236:5 
80,186,188,126, 
169,12,34,244, 
90,166,138,97, 
57,121,64,41, 
186,166,236,169, 
LDL 165, 1774 
185,141,127,90, 
75.,,169:,87,332:, 
92,04 2391, 19, 
7,76,18,241, 


Y 4 


Erypto €; 
c.Init(key,12); 


unsigned char orig[] = “Texto de prueba"; 
unsigned char crypted[sizeof (orig)+1]; 
unsigned char decrypted [sizeof (orig)+1]; 


crypted [sizeof (orig)] = 0; // añadiendo 
// caracteres de terminación nulos 
decrypted [sizeof (orig)] = 0; 


c.Encode (orig, crypted, sizeof (orig)); 
// caracteres de codificación 
c.Decode (crypted, decrypted, sizeof (orig))'; 
//caracteres de descodificación 
SetDlgltemText (IDC_ORIG, (char*) orig); 
// listado de caracteres 
SetDlglItemText (IDC_CRYPTED, (char*) crypted) ; 
SetDlgItemText (IDC_DECRYPTED, (char*) decrypted) ; 


MEJORAS MENORES A PROCDUMP 


Ya se ha comentado la increíble flexibilidad de ProcDump, se estudiará ahora con más 
detalle. La información siguiente contiene ciertas mejoras menores al fichero script.ini que 
permitirá fácilmente descodificar o descomprimir ficheros protegidos con otros codificadores 
o compresores PE, concretamente las distintas versiones de los siguientes: Shrinker, 
Wwpack32, Petite, PECompact, UPX, PESHiELD, Crunch y PE-Encrypter de Stone. 
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[Crunch 1.0] 
L1=LOOK F3,A4 
L2=ADD 2 
L3=BP 
L4=0BJR 
L5=LOOK FF,D2 
L6=BP 
L7=WALK 
L8=0BJR 
L9=LOOK 74,02,58,C3 
LA=ADD 3 
LB=BP 
LC=WALK 
LD=OBJR 
LE=LOOK F3,A4 
LF=ADD 2 
L10=BP 
L11=0BJR 
L12=LOOK FF,A5,F2,2A,00,00 
L13=REPL 90,90,90,90,90,90 
L14=LOOK FF,A5,F2,2A,00,00 
L15=BP 
L16=WALK 
L17=0BJR 
L18=LOOK FF,EO 
L19=BP 
L1A=STEP 
OPTL1=00000000 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


racoaSE 0.971 b] 
L1=LOOK 5A,FF,E2 
L2=WALK 

L3=WALK 

L4=BP 

L5=LOOK F3,A4,E9 
L6=WALK 

L7=WALK 

L8=BP 

L9=STEP 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


[PECompact 0.975 b] 
L1=LOOK 5F,FF,E7 
L2=WALK 

L3=WALK 

L4=BP 

L5=LOOK F3,A4,E9 
L6=WALK 

L7=WALK 

L8=BP 

L9=STEP 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 
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[PESHiELD Secure] 
L1=LOOK 0F,85 
L2=BPF Z 
L3=LOOK CB,8D,B5 
L4=ADD 1 
L5=BP 
L6=STEP 
OPTL1=00000000 
OPTL2=01000001 
OPTL3=01000001 
OPTL4=00010000 
OPTL5=00000000 


[Petite 1.x] 
L1=LOOK 5E,5B,C9,C3,E8 
L2=ADD 4 

L3=BP 

L4=WALK 

L5=0BJR 

L6=LOOK 61,66,9D 
L7=ADD 3 

L8=BP 

L9=WALK 

LA=EIP 

LB=STEP 
OPTL1=00000000 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


[Petite 2.1] 
L1=STEP 

OPTL1=00000000 
OPTL2=0101000 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


[Shrinker 3.3 
Li=L00K FF,75,10,FF,75, 0€,FE,75,08, FE, 55 
L2=BP 

L3=STEP 
OPTL1=00000000 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00010000 
OPTL5=00000000 


[Shrinker 3.4 
L1=LOOK 8D, 4D,E4,51,6A,02,FF,35 

L2=ADD 14 

L3=REPL 90,90 

L4=L00K EF, 75,10,FF, 75, 0€,,PE, 75: 08, FE,55 
L5=BP 

L6=STEP 

OPTL1=00000000 

OPTL2=01010001 

OPTL3=01010001 

OPTL4=00010000 

OPTL5=00000000 
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[STNPE Encrypter 1.xx] 
L1=LOOK FF,EO 

L2=BP 

L3=STEP 
OPTL1=00000000 
OPTL2=01010001 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


[UPX_0.7X-0.8X] 
L1=0BJR 
L2=LOOK EB,10 
L3=BP 

L4=WALK 
L5=0BJR 
L6=LOOK 61,E9 
L7=BP 

L8=STEP 
OPTL1=00000001 
OPTL2=01010101 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


[UPX_0.89.6] 
L1=0BJR 
L2=LOOK EB,O0E 
L3=BP 

L4=WALK 
L5=0BJR 
L6=LOOK 61,E9 
L7=BP 

L8=STEP 
OPTL1=00000001 
OPTL2=01010101 
OPTL3=01010001 
OPTL4=00030000 
OPTL5=00000000 


apa 1] 
L1=LOOK 5D,5B,E9 
L2=BP 

L3=STEP 
OPTL1=00000000 
OPTL2=01000001 
OPTL3=01010001 
OPTL4=00010000 
OPTL5=00000000 


[Wwpack32 11] 

L1=LO0OK 3E,32,65,00,45,E2,F9 
L2=ADD 7 

L3=BP 

L4=DEC 7 

L5=REPL 80,F4,CC,80,F4,66,90 
L6=MOVE FFFFFFF9 

L7=LOOK E2,F9,EB 

L8=ADD 2 

L9=BP 

LA=LOOK 5D,5B,E9 

LB=BP 
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LC=STEP 

OPTL1=00000000 
OPTL2=01000001 
OPTL3=01010001 
OPTL4=00010000 
OPTL5=00000000 


INTERFAZ DE BOUNDSCHECKER 


Por último, unas cuantas funciones de la interfaz de BoundsChecker para 
controlar a SoftICE: 


Obtención de ID 
Descripción: obtiene el ID de SoftICE. 
Ejemplo: mov eax,0 // número de función 0 — Get ID 


mov ebp, 4243484Bh // interfaz BoundsChecker 

INT 3 

emp eax, OEFO1h // valor obtenido, ¿ ID de SoftICE 1D? — esto es, FFO1h 
¡nz SoftICE_inactive 


Definición del punto de corte 
Descripción: define un punto de corte. 
Ejemplo: mov ecx, cs. // ECX = CS (code segment) del punto de corte 


lea edx, greakpoint_location // EDX = dirección a la que se establecerá el 
// punto de corte 


movbh, 0+0.  // BH =tipo 0 de un punto de corte IÓ UTE) + 
// longitud O del punto de corte(BL_BYTE) 


mov eax, OAh // número de función Ah — definición del punto de corte 


INT 3 


Activación del punto de corte 
Descripción: activa un punto de corte, 
Ejemplo: mov eax, 9 // número de función 9 —activa punto de corte 


INT3 
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Desactivación del punto de corte inferior 
Descripción: desactiva el punto de corte inferior. 
Ejemplo: sub edi, edi 
moveax, 8 // número de función 8 — desactiva el punto de corte inferior 


INT 3 
emp eax, OFFFFFEFFh // en caso de error se guarda el valor 
//FFFFFFFEh en el registro EAX 


Jz error 


Obtención del estado del punto de corte 
Descripción: almacena el registro DR6 en el registro EAX, 


Ejemplo: mov eax, 0Ch // número de función Ch— obtiene el estado del punto 
// de corte 
INT 3 


Supresión de puntos de corte 


Descripción: suprime un punto de corte. 
Ejemplo: mov eax, OBh // número de función Bh — suprime un punto de corte 


INT 3 


CAPÍTULO 12 


CONCLUSIÓN 


¿Qué resta por añadir al final? La protección del software debería constituir una 
parte consustancial a su desarrollo y no concebirse como un complemento. La protección 
debería tenerse en cuenta muy al principio del desarrollo de software. Cuanto más 
íntimamente relacionada esté la protección con el desarrollo, mucho mejor será. Resultará 
mucho más difícil anular la protección dada a las distintas partes de un programa desde el 
principio que la que se añade a un par de componentes a posteriori. Por lo tanto, siempre 
será mejor que el autor de un software concreto diseñe la protección por sí mismo antes 
que emplear un sistema de protección externo. 


Muchas personas creen y afirman que la protección de software resulta estéril 
puesto que “siempre habrá alguien que pueda reventarla”. Sin embargo, el quid de la 
cuestión reside en quién anulará la protección, en cuánto tiempo, y a qué precio. Puede 
tomarse perfectamente como ejemplo el caso del juego “Settlers 3”. Los piratas tuvieron 
que esperar a una copia completamente operativa de este juego casi medio año, lo que le 
convirtió posiblemente al juego mejor protegido de la historia. A estas alturas está de más 
discutir acerca de la protección de software. Ya se trató el problema al principio de este 
libro; si el lector discrepa de la afirmación “siempre habrá alguien que pueda reventarla”, 
además no teme enfrentarse a los problemas que ello conlleva y no se escuda en 
afirmaciones con o sin sentido, entonces este libro le vendrá como anillo al dedo. En cierta 
medida, aquellos que consideran inútil la protección del software son responsables de la 
tremenda expansión por todo el mundo de las técnicas conocidas genéricamente como 
cracking. Si no hubiera tantos programas con protecciones tan sencillas de anular, y así es 


378 CRACKING SIN SECRETOS CRA-MA 


la mayoría del software, se vería reducido el gran número de personas que se dedica al 
cracking hoy en día. 


Aunque no resulte muy probable que alguna vez se llegue a conseguir una 
protección invencible, sí es posible crear una protección que resista a los ataques 
realizados con la mayoría de las técnicas de cracking empleadas actualmente. Este tipo de 
protección exige un gran conocimiento y experiencia en cracking. El propósito de este 
libro consiste en dar a conocer las técnicas más importantes de cracking y anticracking. El 
lector las puede emplear para empezar a crear sus propios sistemas de protección y 
también para intentar anularlos. El libro recoge toda la información necesaria organizada 
claramente por capítulos que permite seguir sin problemas el estudio casi interminable de 
estas técnicas. 


Sólo se podrá aprender a proteger el software de forma eficaz convirtiéndose uno 
mismo en cracker. Este principio crea un círculo vicioso paradójico entre el cracking y el 
anticracking que nunca tiene fin. Sólo es cuestión de tiempo el que alguien que esté 
estudiando cracking para aprender a proteger sus programas abuse de su conocimiento con 
otras intenciones, o bien en caso contrario, que algún cracker comience a crear 
protecciones para software, 


El cracking se ha convertido en una ciencia impresionantemente amplia que, como 
casi todo lo relacionado con las tecnologías de la información, está constantemente 
evolucionando, extendiéndose y modificándose, ampliando así los límites de lo posible e 
imposible, de lo conocido y de lo desconocido. 


No se crea nunca a nadie que afirme que su protección es invencible. Sólo alguien 
que ignore lo complejo que se ha vuelto este campo puede realizar tal afirmación. Resulta 
preferible intentar crear una protección propia antes que ponerse en manos de los 
denominados especialistas y empresas profesionales que ocultan su larga experiencia en 
este campo. Aunque muchas de estas personas realizan en verdad un buen trabajo al 
diseñar las protecciones, su conocimiento muchas veces a no llega siquiera al de un 
principiante, condenando así al fracaso a cualquiera de las protecciones que ellos diseñen. 


No se crea que por leer este libro se convierte uno ya en un cracker o en un 
desarrollador de protecciones para software. El camino para convertirse en un profesional 
será largo, además de estar plagado de errores y fracasos. Recuérdese que la información 
es poder, y que ha estado difundiéndose desde el principio del cracking y anticracking 
libremente y a ningún precio, de la misma forma que también así se está entregando al 
lector (tras haber pagado, por supuesto, el precio del libro). En ello está basado el principio 
de enseñar y compartir el conocimiento de estas técnicas: procurar la formación a las 
siguientes generaciones que siempre llegarán algo más allá que sus educadores, 
ensanchando los límites y las posibilidades un poco más. 
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Por consiguiente, nadie debiera sentirse superior a nadie sólo por conocer algo más 
en cierta área y nunca nadie debiera reservarse el conocimiento para uno mismo. Téngase 
siempre presente que todos hemos sido principiantes alguna vez y que apenas hubiéramos 
avanzado nada sin la ayuda de personas que estuvieron dispuestas a compartir sus 
conocimientos con los demás. Esta afirmación también se puede aplicar a ciertos grupos de 
cracking que parecen haber olvidado los objetivos iniciales, centrados únicamente en la 
distribución ilegal de software ofreciendo sus resultados orgullosamente en sus páginas. 
Hoy en día siempre habrá alguien que pueda anular alguna protección de software, pero 
bien pocos son los que enseñan a los demás cómo hacerlo o cómo protegerse frente al 
cracking. 


Aunque aquí concluya el libro, no supone más que el principio para el lector: el 
comienzo del estudio propio del cracking y del anticracking, junto con muchas otras áreas 
en el campo de la tecnología de la información que con tanta rapidez ha empezado a 
controlar el mundo. 
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Ataque y defensa de software 


Cracking no es sinónimo de violación de la protección del software, sino que constituye un método 
para probar la resistencia del programa frente a los posibles ataques y su posterior difusión ilegal. 
Resulta prácticamente imposible crear una protección inviolable, lo que no significa que todas las 
protecciones estén condenadas al fracaso y que no puedan cumplir su misión. El criterio con el 
que se suele medir el éxito de una protección radica en la cantidad de tiempo que permanece 
inexpugnable, lo que, a su vez, repercute en los beneficios derivados de la venta de copias legales 
del software correspondiente. 


Este libro está dirigido tanto a los profesionales como a aquellos principiantes interesados en el 
campo de la protección de software. La obra introduce al lector en los fundamentos del cracking 
y del anticracking y en algunas de las técnicas más avanzadas, y su contenido representa una gran 
compilación de información de casi todas las áreas que comprende esta materia: desde las 
descripciones de sencillos algoritmos de protección hasta la programación de codificadores PE 
propios. Si bien es esencial un conocimiento básico de la programación en ensamblador, no 
resulta imprescindible ya que todo el código mostrado forma parte de otro código realizado con 
lenguajes de mayor nivel. De este modo, resultará accesible incluso para quienes no sepan nada 
de ensamblador. Incluye un apéndice de referencia donde se describen los mandatos en 
ensamblador más comunes. 


Con este libro, el lector conocerá: 


e Las técnicas actuales de protección y sus vulnerabilidades. 

e Los puntos débiles de las protecciones actuales. 

e Los programas y herramientas empleadas por los crackers. 

* Cómo depurar y defenderse de la depuración de un programa. 

+ Cómo desensamblar y defenderse contra el desensamblaje de un programa. 

* Cómo usar y defenderse de los programas FrogsICE y ProcDump. 

* La edición del código del programa. 

+ El formato de fichero PE y los compresores-codificadores PE como soluciones más actualizadas 
frente a la piratería. 

e El cracking como mejor método de prueba de las protecciones. 

+ Información complementaria sobre el cracking. 


Se adjunta un CD-ROM que contiene todo el código de los programas incluidos en el libro y un 

completo paquete de software para crackers y anticrackers: codificadores-compresores PE y sus 

correspondientes descodificadores-descompresores (ProcDump y otros), 

volcadores, generadores de parches, cargadores, editores y escáneres PE, 

calculadoras de desplazamientos, desensambladores, depuradores, programas para 

(o) ocultar los depuradores (como FrogsICE) y muchos otros programas y herramientas. 

También contiene materiales "crackme" para que el lector ponga en práctica los 
conocimientos adquiridos. 


